Repository navigation
Conversation
|
The following comment was made by an LLM, it may be inaccurate: |
There was a problem hiding this comment.
Looks good. I reproduced the stuck prompt on the base with the issue's script (simulated model, shell ask rule, interrupt while the prompt is pending): the TUI kept showing "Permission required" and the reply returned PermissionNotFoundError. With this change, the prompt is dismissed right after the interrupt and the composer comes back. permission.test.ts passes (108), the new interrupt test fails on the base code, and packages/core type-checks.
Public API: no schema changes. The existing permission.replied event (reply: "reject") is now also published when a pending assert wait is interrupted. Clients already handle it by removing the prompt by ID, so this is backwards compatible.
No blocking concerns. The close finalizer rejects pending requests through their deferreds rather than by interruption, so the new handler doesn't send a second event on shutdown. A reply racing an interrupt could at worst produce a second permission.replied for the same ID, which is harmless for current clients. The new interrupt test is enough to cover this fix. The loop over once / always / reject that replaces the old "resolves once" test isn't needed and could be dropped to keep the change minimal.
Related: #52846
|
Thanks for updating your PR! It now meets our contributing guidelines. 👍 |


Issue for this PR
Closes #55678
Type of change
What does this PR do?
Interrupting a tool removed its pending permission request without notifying clients, leaving the Desktop dialog stuck and replies returning 404.
Publish the existing
permission.repliedevent withrejectwhen the permission wait is interrupted so clients dismiss the prompt and restore the composer.How did you verify your code works?
bun typecheckinpackages/coreandbun run checkat the repository root pass.Screenshots / recordings
Before/after TUI screenshots from the bot's separate reproduction are included in this review.
Checklist