Stop stale async flows from closing a palette they do not own - #133
Merged
Conversation
Several palette flows end in setOpen(false) after an await (project create, clone submit, Codex session import), and the open dialog's unmount cleanup closed the store unconditionally. A continuation that outlives its palette session - the user closed or reopened the palette while the request was in flight, or React deferred the cleanup - then slammed a palette it did not own. In the app that meant a clone kicked off and abandoned could close the palette minutes later mid-search; in CI it was the "create-folder affordances" flake (issue #117): under load, a previous test's continuation or deferred cleanup landed during the next test and closed the palette it had just opened. The store now stamps each opening with a generation. Deferred closes go through closeIfGeneration, which no-ops unless the palette is still on the session the flow started under. Synchronous user closes (backdrop, Escape, non-keepOpen items, the settings link) are unchanged. Root-caused by reproducing the flake locally: full browser suite under 6x CPU contention failed within two runs, and a stack trace on the store's close pinned both callers. With the guard, three contended full-suite runs pass; the real app was never affected on the visible path (0/60 repro at 6x CDP throttle before the fix).
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
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.
Stop stale async flows from closing a palette they do not own
Several palette flows end in setOpen(false) after an await (project
create, clone submit, Codex session import), and the open dialog's
unmount cleanup closed the store unconditionally. A continuation that
outlives its palette session - the user closed or reopened the palette
while the request was in flight, or React deferred the cleanup - then
slammed a palette it did not own. In the app that meant a clone kicked
off and abandoned could close the palette minutes later mid-search; in
CI it was the "create-folder affordances" flake (issue #117): under
load, a previous test's continuation or deferred cleanup landed during
the next test and closed the palette it had just opened.
The store now stamps each opening with a generation. Deferred closes go
through closeIfGeneration, which no-ops unless the palette is still on
the session the flow started under. Synchronous user closes (backdrop,
Escape, non-keepOpen items, the settings link) are unchanged.
Root-caused by reproducing the flake locally: full browser suite under
6x CPU contention failed within two runs, and a stack trace on the
store's close pinned both callers. With the guard, three contended
full-suite runs pass; the real app was never affected on the visible
path (0/60 repro at 6x CDP throttle before the fix).