Skip to content

Stop stale async flows from closing a palette they do not own - #133

Merged
badcuban merged 3 commits into
mainfrom
fix/palette-close-flake
Aug 10, 2026
Merged

Stop stale async flows from closing a palette they do not own#133
badcuban merged 3 commits into
mainfrom
fix/palette-close-flake

Conversation

@badcuban

Copy link
Copy Markdown
Collaborator

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).

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).
@vercel

vercel Bot commented Aug 10, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment
Project Deployment Actions Updated (UTC)
threadlines Skipped Skipped Aug 10, 2026 6:53am

Request Review

@github-actions github-actions Bot added size:M vouch:trusted PR author is trusted by repo permissions or the VOUCHED list. labels Aug 10, 2026
@badcuban
badcuban merged commit 487dfd2 into main Aug 10, 2026
15 checks passed
@badcuban
badcuban deleted the fix/palette-close-flake branch August 10, 2026 07:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size:M vouch:trusted PR author is trusted by repo permissions or the VOUCHED list.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant