test(executor): deflake TestQueueTask_ConcurrentDuplicate_DispatchesOnce (GH-4513)

[alekspetrov]

Summary

Fixes GH-4513: TestQueueTask_ConcurrentDuplicate_DispatchesOnce/canary-sandbox-style_path (internal/executor/dispatcher_test.go) was flaky and today killed a correct PR (#4509 / GH-4507) via the ci_pre_merge auto-close path.

Root cause

The test wired the dispatcher to NewRunner() — the real ClaudeCodeBackend — instead of a mock. dispatchMu only serializes QueueTask's duplicate check + insert; it does not cover what happens after. The winning QueueTask call's ensureWorker() starts a background ProjectWorker goroutine that immediately picks up the freshly-queued row, transitions it to "running", and calls runner.Execute against the test's non-existent project path (/Users/pilot-op/Projects/startups/pilot...). Against the real backend, Execute's preflight check (git status chdir) fails fast — observed ~0.5-1s locally, confirmed by direct probe — and marks the row terminal ("failed").

IsTaskQueued only treats queued/pending/running as "active". If that terminal transition landed before all 8 concurrent goroutines made it through dispatchMu's serialized check, a "loser" goroutine checking afterward no longer saw the row as active and fell through to beginWithGenerationRetry's legitimate dead-claim repick path — minting a second real dispatch and a second nil-error QueueTask return, inflating successes past 1. Since dispatchMu fully serializes the 8 calls' fast SQL work but the real backend's failure latency isn't bounded relative to that, this is a genuine race whose outcome depends on CI scheduler/load — exactly the kind of thing that doesn't reproduce reliably locally (confirmed: 100 local runs all passed before the fix) but bites under CI conditions.

This is unrelated to PR #4509/GH-4507's actual change (internal/executor/intent_judge.go, preflight-cap logic) — the subtest failure was pure test-harness flake, not a regression from that PR.

Fix

Swap in a blockingBackend (Execute blocks on <-ctx.Done()) with skipPreflightChecks/config set the same way sibling tests in this file already do for mock backends. This pins the winning execution row at "running" for the entire concurrent-dispatch assertion window deterministically — no sleeps, no timing assumptions — removing the real backend's uncontrolled completion latency as a race variable entirely. The row only transitions once dispatcher.Stop() cancels the context, which happens after all assertions in both subtests have already completed.

No assertion was weakened — both subtests still verify exactly one dispatch out of concurrency (8) concurrent QueueTask calls.

Test plan

• go build ./...
• go test ./internal/executor/... (full package, includes new-etc)
• go test -race -run 'TestQueueTask_ConcurrentDuplicate_DispatchesOnce' -count=200 ./internal/executor/ — passes
• go test -race -run 'TestQueueTask_ConcurrentDuplicate_DispatchesOnce' -count=50 -cpu 1,2,4 ./internal/executor/ — passes
• gofmt -l clean on the changed file

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!