stablyai/orca · warning · Error

A previous reset attempt for this target still has an unknow

Error message

A previous reset attempt for this target still has an unknown outcome.

What it means

Thrown by the default/system-target branch of consumeCurrentRateLimitResetCredit (the path taken when no managed account is selected for the current runtime target). The guard hasPendingResetForTarget found a reset-credit attempt still in the 'providerPending' state for this same target, so the service refuses to start a second concurrent default reset. It exists because a pending provider mutation's outcome is unknown and launching a parallel reset could double-spend or corrupt the rate-limit credit ledger.

Source

Thrown at src/main/codex-accounts/service.ts:425

      if ('status' in result) {
        throw new Error('The Codex account or reset offer changed before reset.')
      }
      return { outcome: result.outcome, state: result.rateLimits }
    }

    return this.serializeMutation(async () => {
      if (this.resetLedgerLoadError) {
        throw this.resetLedgerLoadError
      }
      const target = this.rateLimits.getState().codexTarget
      if (!sameRateLimitTarget(target, initialTarget)) {
        throw new Error('The active Codex rate-limit target changed before reset.')
      }
      if (getSelectedCodexAccountIdForTarget(this.store.getSettings(), target)) {
        throw new Error('The selected Codex account changed before reset.')
      }
      if (this.hasPendingResetForTarget(target)) {
        throw new Error('A previous reset attempt for this target still has an unknown outcome.')
      }
      const codexHomePath = this.runtimeHome.prepareForRateLimitFetch(target)
      return this.rateLimits.consumeCodexRateLimitResetCredit({
        idempotencyKey: randomUUID(),
        target,
        codexHomePath
      })
    })
  }

  private getPendingResetAttemptForAccount(
    target: RateLimitRuntimeTarget,
    account: CodexManagedAccount
  ): { idempotencyKey: string; expectedScope: CodexResetCreditExpectedScope } | null {
    const accountScopeKey = resetAccountScopeKey({
      target,
      accountId: account.id,
      accountRevision: account.updatedAt

View on GitHub (pinned to 1136503c6a)

Solutions

  1. Wait for the in-flight provider mutation to settle, then retry consumeCurrentRateLimitResetCredit — once state flips to 'settled' the guard clears.
  2. If the app restarted with a stuck providerPending attempt (provider call is gone), trigger a reconciliation / re-resolve of the durable attempt for that target, or switch the selected account so the account-scoped reset path is used instead of the default-target path.
  3. If a removed account orphaned the pending attempt, confirm discardResetAttemptsForRemovedAccount ran (service.ts:671); removing then re-adding the account purges it.
  4. As a last resort, inspect the CodexResetCreditAttemptLedger for stale providerPending entries for this target and reconcile them via the account-management flow.

Example fix

// before: concurrent default-target resets
service.consumeCurrentRateLimitResetCredit() // throws [900] if one is pending

// after: serialize/await default resets per target
await service.consumeCurrentRateLimitResetCredit()
// surface 'a reset is already in progress' to the UI instead of re-invoking
Defensive patterns

Strategy: retry

Validate before calling

// Avoid invoking a second default-target reset while one is pending.
const pending = [...service.listAccounts().accounts].length === 0 && /* default target */ true
// Orca exposes no direct public probe; track in-flight default resets in the UI:
if (defaultResetInFlight) { show('A reset is already in progress'); return }
await service.consumeCurrentRateLimitResetCredit()

Try / catch

try {
  await service.consumeCurrentRateLimitResetCredit()
} catch (error) {
  if (error instanceof Error && error.message.includes('unknown outcome')) {
    // a prior default-target attempt is still pending; surface 'in progress' and retry after it settles
    return { status: 'reset-in-progress' }
  }
  throw error
}

Prevention

When it happens

Trigger: Calling consumeCurrentRateLimitResetCredit() while a prior default-target reset attempt is still providerPending — e.g. the provider RPC is still in flight, OR the app restarted and hydrateResetCreditAttempts reloaded a providerPending attempt from the durable CodexResetCreditAttemptLedger (service.ts:612) without ever settling it.

Common situations: App crash / force-quit during a reset leaves a providerPending entry in the persisted ledger; on next launch every default reset is blocked until that entry is reconciled. Also seen when two UI surfaces (switcher + banner) both trigger a reset for the system-default target in quick succession.

Related errors

AI-assisted analysis of stablyai/orca@1136503c6a (2026-08-12). Data as JSON: /api/errors/73ed8d2636ee8a3d. Report an issue: GitHub.