retry state cannot be explicitly stopped, making revert/reset ineffective and preventing context cleanup after quota recovery

[sch246]

Description

Description

When a session enters retry state after quota/capacity exhaustion, I can lose control of the session even after I recover the quota and want to clean up the failed/retry noise from the conversation.

A typical sequence looks like this:

1. The model/provider hits a quota/capacity exhaustion condition.
2. OpenCode enters retry behavior and keeps trying to continue the run.
3. I recover the quota / top up credits.
4. I try to use Desktop UI actions such as "Reset to this point" (or equivalent revert/reset flow) to roll back the repeated quota-failure / unknown-error messages and clean the context.
5. The reset/revert appears to take effect briefly, but then the session immediately continues again, appends another follow-up message, and the rollback is effectively undone.
6. No matter how many times I interrupt/cancel, it can keep re-entering the same loop and stay stuck on "Thinking".
7. The only reliable way I have found to stop it is to close the entire application.

This makes it practically impossible to recover control of the session and clean the context after quota recovery.

Why this is a real usability problem

Even if the upstream/provider error is transient or quota-related, once the session is in retry state there appears to be no reliable way to:

• explicitly stop the retry
• stabilize the session
• clean up the repeated failure messages
• regain control without closing the whole app

In practice, the retry loop can block recovery actions instead of helping recovery.

Additional notes

There may also be a secondary issue where the repeated "request failed / unknown error" messages are themselves making the context worse, and the retry path might still be performing real calls while degrading the session further.

However, the main problem in this report is not the original provider error itself — it is that once retry is active, I cannot reliably stop it and perform cleanup/revert actions.

Expected behavior

At minimum, users should be able to explicitly stop/cancel the current retry state and regain control of the session without quitting the app.

A retrying session should not keep overriding or invalidating user recovery actions.

Actual behavior

The session can continue retrying indefinitely / repeatedly, re-append messages after a revert/reset attempt, stay stuck on "Thinking", and force a full app shutdown to stop the loop.

Suggested directions

I think there are two related improvements that would help:

1. Retry should support an explicit termination path

   • users should be able to stop/cancel the current retry state
   • retry should not require closing the whole app to stop

2. Retry policy should be configurable

   • max attempts
   • exponential backoff strategy
   • max delay / retry budget
   • or similar bounded retry controls

Even if the default remains "retry aggressively", users need a reliable explicit stop path.

Plugins

DCP, oh my opencode

OpenCode version

1.14.33

Steps to reproduce

1. Run OpenCode Desktop on Windows x64.
2. Use a provider/model until it hits quota/capacity exhaustion and enters retry behavior.
3. Restore quota / top up credits.
4. Attempt to use Reset to this point / revert-like recovery to remove the repeated failure messages and clean the context.
5. Observe that the session can resume appending messages, effectively undoing the rollback, and remain stuck in a retry/thinking loop.
6. Try interrupt/cancel repeatedly.
7. Observe that the loop may continue until the entire app is closed.

Screenshot and/or share link

Operating System

Windows 10 (x64)

Terminal

not a terminal,, that dosen't matter

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Session retry loops forever — no max attempt cap or configurable limit #25733: Session retry loops forever — no max attempt cap or configurable limit (same core problem: retry cannot be stopped, requests configurable limits)
• [Bug]: Session processor retries indefinitely with unbounded exponential backoff — no max retries or circuit breaker #17648: Session processor retries indefinitely with unbounded exponential backoff — no max retries or circuit breaker (infinite retry loop with no way to stop)
• Session retries forever on weekly rate limit errors #24011: Session retries forever on weekly rate limit errors (session retries indefinitely, user must press Esc)
• fix(session): SessionRetry.policy() retries forever with no max attempt count #21960: fix(session): SessionRetry.policy() retries forever with no max attempt count (retry has no max attempt cap)

Your report highlights a specific additional symptom — that reset/revert actions are overridden by the active retry loop — which may be worth noting as a distinct aspect if the above issues don't cover it. Please review those issues and let us know if your report covers something not addressed there.

[sch246]

A clarification after more testing:

My core problem is not only that retry cannot be stopped.

The more serious problem is:

after enough repeated quota-failure / unknown-error / retry pollution, the session becomes unusable, and the active retry loop also prevents recovery actions like revert/reset/fork.

So the session gets stuck in a worst-case state:

• it cannot continue meaningfully because the history has been polluted too much
• it cannot reliably recover because retry keeps taking over
• revert/reset is not stable
• fork may also become impractical or inaccessible in this state
• the app can remain stuck in Thinking
• the only escape may be closing the entire application

So from a user perspective this is really a session recovery failure:

the session is neither usable nor recoverable once retry pollution crosses a certain threshold.

I think this is more specific than the existing “retry loops forever / no max attempt cap” reports.

Those issues cover the retry-policy side.
This issue is about the combination of:

1. retry pollution making the session unusable, and
2. active retry blocking the normal recovery paths.

If there is already an intended recovery workflow for this case, I would really like to know it.
Otherwise I think OpenCode needs a reliable recovery path for polluted sessions:

• explicitly stop/freeze retry
• prevent further append from pending retry continuation
• allow stable revert/reset/fork after stop

[sch246]

Update:

After updating to the latest version, I can now revert/reset directly and it no longer immediately falls back into retry.

So at the moment, the problem seems to be gone for me.

I’m not sure what changed:

• maybe updating to the latest version fixed it,
• maybe one of my earlier actions happened to break the retry loop,
• or maybe the original behavior was caused by a race / intermittent state.

Because of that, I do not currently have a reliable reproduction anymore, and I’m not planning to actively try to reproduce it right now.

So for now, please treat this as:

• a previously observed recovery/control failure around retry + revert/reset,
• but currently not reproducible for me on the latest version.

If I hit it again and can narrow it down better, I’ll add reproduction details.