fix(desktop): block a second submit while a task is being created - #80137
Conversation
The `isCreatingTask` state flag only blocks a repeat submit once React has re-rendered, and the cloud-usage / worktree-branch pre-flight awaits run inside that window. Two quick Enters both cleared the guard and created two tasks. Add a synchronous ref guard around the submit, and raise the in-flight state at the keystroke so the send button and editor show the pending state during the pre-flight instead of only after it. Generated-By: PostHog Code Task-Id: ede35980-160f-474e-8b38-243396877386
|
😎 Merged successfully - details. |
|
Hey @pauldambra! 👋 It looks like your git author email on this PR isn't your
You can fix it for this repo with: git config user.email "you@posthog.com"Or set it globally with |
|
React Doctor found no issues in the changed files. 🎉 Reviewed by React Doctor for commit |
… flag Drop the ref. A keydown is a discrete event, so React commits the `setIsCreatingTask(true)` re-render before the next keypress is handled — once the flag is raised above the pre-flight awaits, `canSubmitBase` blocks the repeat submit on its own. Generated-By: PostHog Code Task-Id: ede35980-160f-474e-8b38-243396877386
pauldambra
left a comment
pauldambra
left a comment
There was a problem hiding this comment.
Note
🤖 Automated comment by QA Swarm — not written by a human
QA Swarm review complete. See inline comments.
|
Note 🤖 Automated comment by QA Swarm — not written by a human Multi-perspective review: router (cheap-first pass) + delegated reviewers (qa-team, paul-reviewer, xp-reviewer, security-audit as warranted) Verdict: ✅ APPROVE (round 1 @ e43cac1)The fix is correct for the bug it targets, and the two findings are a UX trade-off and a durability nit — neither blocks merge. Key findings
ConvergenceNone — a single router pass covered the change; danger was assessed LOW with HIGH confidence, so no delegation was warranted. Reviewer summaries
Automated by QA Swarm — not a human review |
![stamphog[bot]](https://avatars.githubusercontent.com/in/3000332?s=60&v=4){kind=small}
There was a problem hiding this comment.
Frontend-only race-condition fix reordering an existing flag/try-finally in the desktop task composer; diff matches the description, no risky-territory surface touched, and an automated review plus bot reactions are net positive with no unresolved concerns.
- 👍 on the PR from chatgpt-codex-connector[bot], hex-security-app[bot].
Gate mechanics and policy version
| Gate | Result | |
|---|---|---|
| prerequisites | ✓ | all clear |
| deny-list | ✓ | no deny categories matched |
| size | ✓ | 508L, 1F substantive — within ceiling |
| tier | ✓ | T1-agent / T1d-complex (508L, 1F, single-area, fix) |
| stamphog 2.0.0b4 | .stamphog/policy.yml @ 85af931 · reviewed head e43cac1 |
1 participant
Problem
Pressing Cmd+Enter twice in the desktop task composer starts two identical tasks.
isCreatingTask— the flag that disables the send button and the editor's Enter shortcut — is only raised after the cloud-usage and worktree-branch pre-flight checks have awaited. A second Enter that lands during those round trips passes every guard and creates a duplicate.That pre-flight window is also where the composer shows no pending state at all, which is what invites the second press.
Changes
setIsCreatingTask(true)moves above the pre-flight awaits, and the rest of the submit is wrapped in thetrythat its existingfinallyalready resets. No new guard: a keydown is a discrete event, so React commits the re-render before the next keypress is handled, andcanSubmitBase(which already carries!isCreatingTask) blocks the repeat submit on its own.The composer also shows its pending state for the whole create rather than only after the pre-flight.
Both callers of the hook —
TaskInputandChannelHomeComposer— get this for free; they already route every submit path throughhandleSubmit.Most of the diff is the re-indent from the new
try. Review with?w=1— the real change is five lines.How did you test this code?
Not manually tested — I could not run the Electron app in this environment.
Automated checks I ran:
pnpm --filter @posthog/ui typecheckandbiome checkon the changed file, both clean.No test added.
useTaskCreationpulls in roughly thirty injected hooks, stores, and services, so a unit test around it would be mostly mocking and would break on any unrelated import change. Worth revisiting if this hook gets a test harness.Automatic notifications
Docs update
None.
🤖 Agent context
Autonomy: Human-driven (agent-assisted)
Reported from Slack: a user pressed Cmd+Enter, found the loading state too subtle, pressed again, and ended up with two identical tasks.
I first checked the web
/taskscomposer (products/posthog_ai/frontend), where every submit path funnels through onesendDisabledReasoncheck and is already safe. The desktop hook is the one with the gap.The first version of this PR added a
useRefre-entrancy guard on top of the state flag. On review that was unnecessary: React flushes discrete-event state updates synchronously, so the existing flag is sufficient once it is raised early enough. The ref only covered two submits dispatched inside a single tick, which no user input path produces. Dropping it left the smaller change.Skills invoked: none.
Created with PostHog from a Slack thread