bug: pulse dispatches concurrent workers for tasks already committed directly to main, wasting tokens

[superdav42]

Description

The pulse dispatched multiple workers concurrently for the same set of tasks (t153–t160, 7 UI tasks), and at least one worker committed the work directly to main before the others finished. The result was 3× the token spend for 1× the output — two workers' entire sessions were wasted.

Observed sequence (2026-04-04, 08:00–09:00 UTC, repo: Ultimate-Multisite/gratis-ai-agent):

1. 08:22 — Worker A commits t153–t160 directly to main (7 commits, bypassing PR flow)
2. 08:24 — Worker B opens PRs feat: define model-specific subagents for cross-provider routing (t132.1) #758–fix: add missing log_verbose function to supervisor-helper.sh #764 for the same 7 tasks (2 minutes after Worker A finished)
3. 08:32 — Pulse closes PRs feat: define model-specific subagents for cross-provider routing (t132.1) #758–fix: add missing log_verbose function to supervisor-helper.sh #764 as CONFLICTING — Worker B's entire session discarded
4. 08:37 — Worker C commits t153–t160 directly to main again (7 more identical commits)
5. 08:38 — Pulse marks t153–t160 complete

Three workers ran the same 7 tasks. Only one was needed.

Estimated waste: ~560K tokens (2× the useful work), roughly $5–15 at Sonnet pricing.

Expected Behavior

Before dispatching a task, the pulse should check whether a commit touching the relevant files has already landed on main since the task was opened. If yes, mark the task complete and skip dispatch entirely.

At minimum: if a task is already assigned to a worker (GitHub assignee), do not dispatch a second worker for it.

Root Cause Analysis

Two separate gaps:

1. No pre-dispatch check against recent main commits.
The dispatch pipeline checks GitHub issue state and assignee, but does not check whether commits matching the task's scope have already landed on main. A worker that commits directly to main (without a PR) completes the work invisibly — the issue stays open until the pulse's chore: mark tXXX complete commit runs, which happens after dispatch decisions for the next cycle.

2. The CONFLICTING close comment is misleading.
When the pulse closes a PR as conflicting, it says:

"The linked issue (if any) remains open for a worker to re-attempt with a fresh branch."

This implies re-dispatch is needed. In this case the issue was already done — the comment caused a third worker to be dispatched unnecessarily (Worker C's direct commits at 08:37).

Steps to Reproduce

1. Have multiple workers enabled with pulse: true on a repo
2. Dispatch 7+ tasks simultaneously
3. One worker commits directly to main (no PR) and finishes before others open their PRs
4. Observe: pulse closes the other workers' PRs as conflicting, then dispatches again

Environment

• aidevops version: 3.6.118
• AI Assistant: Claude Code (claude-sonnet-4-6)
• OS: Ubuntu 24.04.4 LTS
• Shell: bash 5.2.21(1)-release
• gh CLI: 2.45.0

Proposed Fix

Short term: In pulse-wrapper.sh's dispatch loop, before dispatching a task, run:

git log origin/main --since="$(gh issue view $issue_number --json createdAt -q .createdAt)" \
  --oneline | grep -i "$task_id"

If a match is found, mark the issue complete and skip dispatch.

Also: Change the _close_conflicting_pr comment to not say "remains open for a worker to re-attempt" — instead check whether the work is already on main and say so explicitly. A misleading close comment is itself a dispatch trigger.

Related Issues

• bug: supervisor pulse dispatches duplicate workers due to non-normalized title matching #2310 (closed) — duplicate workers from non-normalized title matching (different failure mode)
• Bug: dispatch-dedup-helper.sh reports DUPLICATE for dead PIDs, blocking valid dispatch #5662 (closed) — dispatch-dedup-helper.sh false positives on dead PIDs (different failure mode)

[github-actions]

Thanks for the report, @superdav42.

This issue has been queued for maintainer review. A maintainer will review it and either:

• Approve it using: sudo aidevops approve issue 17574
• Ask for more information if the report needs clarification
• Close it if it's a duplicate or out of scope

Tip: For faster, higher-quality issue reporting, use /log-issue-aidevops in your AI assistant session. It gathers diagnostics automatically and checks for duplicates.

[github-actions]

The needs-maintainer-review label was re-applied automatically.

Removing this label requires a cryptographic approval — even for maintainers. This ensures every approval is auditable and cannot be forged by automation.

To approve this issue, run from your terminal:

sudo aidevops approve issue 17574

This signs the approval with a root-protected key and posts a verifiable comment.

[marcusquinn]

Review: Approved

Issue Validation

Check	Result	Notes
Reproducible	Yes	Confirmed by code review — the gap exists in the current dedup pipeline
Not duplicate	Yes	Related issues (#2310, #5662, #6419, #6696, #15317) address different failure modes. This specific gap is new
Actual bug	Yes	7-layer dedup in check_dispatch_dedup() has no layer checking for commits already on origin/main
In scope	Yes	Token waste from duplicate dispatch is a core pulse reliability concern

Root Cause

Two confirmed gaps:

1. No main-commit check in dispatch pipeline. The 7 dedup layers (in-flight ledger, process match, title key, merged PR evidence, dispatch comment, assignee guard, optimistic lock) never check git log origin/main for commits referencing the task ID. A worker that commits directly to main completes work invisibly to the dedup system.

2. Misleading _close_conflicting_pr comment. At pulse-wrapper.sh:8466, the close comment unconditionally says "remains open for re-attempt" without checking whether the conflict was caused by work already being on main — triggering unnecessary re-dispatch.

Refinements to Proposed Fix

• Use gh api instead of local git log — the pulse may not have a local checkout for all repos:

  gh api "repos/${repo_slug}/commits?sha=main&since=${issue_created_at}" \
    --jq ".[].commit.message" | grep -iE "(t${task_num}|#${issue_number})"

• Match both task IDs and issue numbers — commit messages may use tNNN or #NNN
• Make the conflicting-PR close comment conditional — detect if work is already on main and adjust message to "work already committed to main" instead of "remains open for re-attempt"
• Separate concern: a guard preventing direct-to-main pushes by workers would prevent the root trigger entirely — worth a separate issue

Implementation Guidance

• Add Layer 8 to check_dispatch_dedup() (pulse-wrapper.sh ~line 6244), between Layer 4 and Layer 5
• Modify _close_conflicting_pr() (pulse-wrapper.sh ~line 8460-8472) to check for main-landed work before composing the close comment
• Test: dispatch a task, commit directly to main, verify next pulse cycle skips dispatch

Verdict

Approve — real, confirmed gap with clear token-waste impact. Scope is tight and well-defined.

---

aidevops.sh v3.6.118 plugin for OpenCode v1.3.17 with claude-opus-4-6 spent 10m and 652 tokens on this with the user in an interactive session. Overall, 12m since this issue was created.

[marcusquinn]

Maintainer Approval (cryptographically signed)

APPROVE:issue:marcusquinn/aidevops:17574:2026-04-06T16:05:10Z

-----BEGIN SSH SIGNATURE-----
U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgeu2Ii1FVuPun+49v51FONnIskf
TinwsexuL1MNgCwJ8AAAAQYWlkZXZvcHMtYXBwcm92ZQAAAAAAAAAGc2hhNTEyAAAAUwAA
AAtzc2gtZWQyNTUxOQAAAEBD0P+Qg6jh2iZWcGNpk5WZDpJFKSbEDZ2RiAOGa9DvPTZyna
yBnKbu1m5hAs03dc+sQ5t8SmoNill95WjnIlcE
-----END SSH SIGNATURE-----

This approval was signed with a root-protected SSH key. It cannot be forged by automation.

[marcusquinn]

DISPATCH_CLAIM nonce=54fd2bbd8aefa4dda7ef84e0d0888841 runner=marcusquinn ts=2026-04-06T16:13:13Z max_age_s=1800