Repository navigation
fix(gui-plugins): dedupe new worktree actions - #60171
DevDengChao wants to merge 2 commits into
Conversation
Keep the in-flight location move on the plugin instance, keyed by session, so closing and reopening the menu cannot start a second worktree creation. Fixes anomalyco#60167 Co-authored-by: DeepSeek V4.1 Flash <noreply@opencode.ai>
![opencodejr[bot]](https://avatars.githubusercontent.com/in/5497873?s=60&v=4){kind=small}
There was a problem hiding this comment.
This fixes the bug. I ran the #60167 reproduction in the web UI with Playwright. On the base, after closing and reopening the location card while the first creation is pending, New worktree is enabled again and a second POST /api/worktree goes out. With this PR it shows as disabled and only one request is sent. Your new regression test fails on the base and passes here, and session-summary.spec.ts passes in full. The screenshots below show the reopened menu before and after the change.
Public API: unchanged. moves is a new prop on internal components of the details plugin, not on the plugin API.
I found nothing in the change that blocks a merge. The pending state is keyed by session.key, which the plugin API documents as kept across a move, so finally clears the same key that begin set.
There was a problem hiding this comment.
The new commit only merges dev, and your change is the same as before. I ran the #60167 reproduction and your regression test again on the new head. Both pass: New worktree stays disabled after reopening the card, and only one create request is sent. tsc -b passes in packages/gui-plugins. Public API: unchanged. No new concerns.
Issue for this PR
Fixes #60167
Type of change
What does this PR do?
The New worktree action only tracked its in-flight state inside the menu component, which unmounts when the menu closes. Reopening the menu during a pending creation allowed a second request, so two worktrees were created.
The in-flight state now lives for the plugin instance and is keyed by the session key, so every menu instance sees it. It covers all move destinations, and the action stays disabled until the first move settles.
How did you verify your code works?
Added an e2e regression in
packages/app/e2e/regression/session-summary.spec.ts. It holds the firstPOST /api/worktree, reopens the location menu, and asserts that New worktree is disabled and only one request was sent. It fails on the previous code and passes with the fix.bun run test:e2e:built -- e2e/regression/session-summary.spec.ts(17 passed, fully parallel)bun run typecheck:tscinpackages/gui-pluginsandpackages/appbun run lint:changedVisual
Open the animated SVG
Screenshots / recordings
The e2e regression asserts the visible disabled state. The animated SVG above shows the before/after behavior.
Checklist