Repository navigation
fix(tui): recover from terminal forms - #44516
Merged
Merged
Conversation
jinhuang712
pushed a commit
to jinhuang712/opencode
that referenced
this pull request
Sep 26, 2026
This was referenced Oct 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Recover the normal TUI composer when a cached form has already disappeared or been settled elsewhere. Replying or cancelling a stale form now treats both
FormNotFoundErrorandFormAlreadySettledErroras terminal outcomes and removes the matching form from the local projection immediately.This supersedes #44507 with the review findings addressed.
Before / After
Before: If the TUI missed a form settlement event, the stale prompt remained active. A reply or cancellation returned 404 or 409, displayed an error, and continued blocking the normal composer. The previous fix hid the component while waiting for a list refresh, which could leave a blank blocked footer when refresh failed.
After: Form settlement lives in the client data layer. Successful, missing, and already-settled outcomes remove the matching projected form synchronously, so the keyed form component unmounts and normal keymap/composer cleanup runs immediately. Revalidation is advisory; a failed refresh cannot re-block the composer.
How
packages/client/src/solid/data.tsadds projection-aware formreplyandcanceloperations, preserving global-form location headers and accepting 404/409 as terminal only when the error identifies the submitted form.packages/tui/src/routes/session/form.tsxdelegates settlement to the data layer instead of coordinating API errors and cache state itself.packages/plugin/src/tui/context.tsexposes the domain-level form operations to TUI data consumers.packages/tui/test/cli/tui/form.test.tsxcovers reply and cancellation recovery for 404 and 409, plus failed background revalidation.Scope
This does not change form protocol or server behavior. Duplicate in-flight form submissions remain outside this stale-projection recovery fix.
Testing
bun run test test/cli/tui/form.test.tsxfrompackages/tui(25 passed)bun run test test/solid-data.test.tsfrompackages/client(3 passed)bun typecheckfrompackages/tui,packages/client, andpackages/pluginbun run lint(0 errors; pre-existing warnings remain)Flow