| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
Resume queued follow-ups when Esc aborts a busy session instead of leaving them paused in the app dock, and abort the active CLI turn so the local prompt queue can continue. Co-authored-by: Cursor <cursoragent@cursor.com>
|
Thanks for your contribution! This PR doesn't have a linked issue. All PRs must reference an existing issue. Please:
See CONTRIBUTING.md for details. |
Sorry, something went wrong.
|
The following comment was made by an LLM, it may be inaccurate: Based on my search, I found several related PRs that address similar interrupt and queue handling issues: Potentially Related PRs:
These PRs share the same domain of interrupt handling, queue management, and ESC key behavior. PR #34530 and #33808 are particularly close in scope to the current PR #35008, addressing queue behavior after interrupt in both the TUI and web app contexts. |
Sorry, something went wrong.
|
Thanks for updating your PR! It now meets our contributing guidelines. 👍 |
Sorry, something went wrong.
Sorry, something went wrong.
Overlap with #33808I compared this PR against #33808 (same issue, #33812). Here's the exact breakdown: Identical / equivalent (web app)Both PRs fix the same root cause in packages/app/src/pages/session.tsx:
Functionally the same: Esc only interrupts the current turn; queued follow-ups resume via the existing idle auto-send path. Only in #33808
On current dev, follow-up wiring goes through createSessionComposerRegionController + PromptInput directly (no onAbort on composer region), so that file may already be obsolete relative to this branch. If #33808 merges first, this PR shouldn't need that hunk. Only in #35008
This is the direct CLI mode (opencode run) path: interrupt previously only hit the server abort API and could leave the local prompt queue stuck with a queued message visible in the footer. Not covered by either PR
Suggested path for maintainers
Test screenshots attached in thread. Local verification:
|
Sorry, something went wrong.
Drop the duplicate web app followup.paused fix (anomalyco#33808 owns that surface). Keep opencode run queue interrupt wiring, expose pending queue count, and show a footer status hint when interrupting with queued prompts. Co-authored-by: Cursor <cursoragent@cursor.com>
|
Scope update: dropped the duplicate packages/app follow-up fix — #33808 already covers that surface. This PR is now CLI-only (opencode run):
Stacks on #33808 for #33812. Happy to rebase once that lands. |
Sorry, something went wrong.
|
Automated PR Cleanup Thank you for contributing to opencode. Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions. This PR was closed because it matched the following cleanup criteria:
PRs created within the last month are not affected by this cleanup. If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate. Thanks again for taking the time to contribute. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Issue for this PR
Closes #33812 (CLI / opencode run scope)
Type of change
What does this PR do?
CLI-only — the web app follow-up queue fix lives in #33808; this PR no longer touches packages/app.
In direct CLI mode (opencode run), interrupt only called session.abort on the server and did not abort the active turn's local AbortSignal, so the prompt queue could stay blocked behind an in-flight turn. This wires Esc interrupt to:
Stacks cleanly on top of #33808 for the shared issue.
How did you verify your code works?
Manual checks still needed:
Screenshots / recordings
Terminal captures via rudycanshoot (attached in PR comments):
Checklist