bug: orchestrator dispatches responder twice from duplicate triggers

[microsasa]

What happened

When PR #163 merged to main, two orchestrator runs fired simultaneously:

1. push: branches: [main] trigger (16:19:03)
2. workflow_run trigger from the old responder completing (16:19:52)

Both orchestrator runs saw the same state on PR #162 (4 unaddressed threads, CI passing) and both dispatched the responder via gh workflow run. Result: two responder runs for the same PR.

Why

The orchestrator has multiple event triggers that can fire close together:

• push fires on merge
• workflow_run fires when responder/ci-fixer/CI complete
• pull_request_review fires on Copilot review

The orchestrator's concurrency: cancel-in-progress: true prevents multiple orchestrator runs from overlapping, but if two complete before either dispatches, both can dispatch the responder.

The responder has concurrency too (gh-aw-${{ github.workflow }}) but the compiled lock file may not set cancel-in-progress: true, so both runs execute.

Impact

The second responder run will see aw-review-response-attempted label (added by the first) and noop. Wasted compute but no functional harm.

Fix options

1. Orchestrator checks if responder is already running before dispatching — query gh run list --workflow=review-responder.lock.yml --status=in_progress
2. Add a dispatch label (e.g., aw-responder-dispatched) that the orchestrator sets before dispatching and checks before dispatching again
3. Deduplicate triggers — remove push trigger if workflow_run covers the same case

Related

• perf: rewrite pipeline orchestrator as regular GitHub Action (yml) #135 — Pipeline orchestrator

[microsasa]

Update: re-evaluating severity

After observing the pipeline in production, the duplicate triggers may not be a real problem:

• Each orchestrator run takes ~7 seconds and exits quickly when there's nothing to do
• The concurrency group (cancel-in-progress: true) ensures only one runs at a time — duplicates get cancelled
• A single push to main can fire up to 4 orchestrator runs (push, workflow_run from CI, pull_request_review from Copilot, workflow_run from Quality Gate), but this is just event-driven architecture working as designed — the orchestrator's job is to react to events and check for work

The burst of 30 runs we saw on March 19 was NOT from normal duplicates — it was caused by the quality gate lock file being broken (hash mismatch), which caused the QG to fail repeatedly, each failure triggering another orchestrator run via workflow_run. That root cause was fixed in PR #170.

Recommendation: Consider downgrading from bug to nice-to-have optimization. The current behavior is correct, just slightly wasteful (~7s of runner time per duplicate).

[microsasa]

Implementation plan

Three changes to the orchestrator:

1. Remove push trigger — cron (every 5 min) now covers post-merge dispatch. The push trigger caused duplicate runs alongside workflow_run.
2. cancel-in-progress: false — queue runs instead of cancelling. Queued runs see the state left by the previous run (e.g., aw-dispatched label) and won't double-dispatch.
3. Check for in-flight implementers before dispatching — gh run list --workflow=issue-implementer.lock.yml --status=in_progress,queued. Skip dispatch if any are running.