[deep-report] Fix: mixed pull_request+slash_command workflows skip cancel-in-progress, causing spurious 0-job "failure" runs under rapid PR pu #65455

Description

detectTriggerType (pkg/workflow/tools.go:130-166) classifies a workflow as isCommandTrigger=true whenever its frontmatter on: map contains a slash_command key — with no check for a co-existing plain pull_request trigger. shouldEnableCancelInProgress (pkg/workflow/concurrency.go:358-369) then unconditionally returns false for any command-trigger workflow, so GenerateConcurrencyConfig (pkg/workflow/concurrency.go:15-44) falls through to queue: max instead of cancel-in-progress: true — even though the same concurrency group (keyed by PR/issue number) is also used by the workflow's ordinary pull_request event runs, which should cancel a stale review when a newer commit lands.

33 workflows combine slash_command with pull_request triggers (e.g. ponytail-reviewer.md, pr-code-quality-reviewer.md, mattpocock-skills-reviewer.md, test-quality-sentinel.md, design-decision-gate.md). By contrast, impeccable-skills-reviewer.md has no slash_command trigger, correctly gets cancel-in-progress: true, and is unaffected.

Live verification:

$ DEBUG=workflow:concurrency ./gh-aw compile .github/workflows/ponytail-reviewer.md
workflow:concurrency Generating concurrency config: isCommandTrigger=true
workflow:concurrency cancel-in-progress disabled: command trigger workflow
workflow:concurrency Enabling queue: max for top-level concurrency group

$ DEBUG=workflow:concurrency ./gh-aw compile .github/workflows/impeccable-skills-reviewer.md
workflow:concurrency Generating concurrency config: isCommandTrigger=false
workflow:concurrency cancel-in-progress=true for workflow on="on": ...
workflow:concurrency Enabling cancel-in-progress for concurrency group

Observed production impact: on 2026-10-03, PR #65410 received several rapid Copilot pushes; 6 PR-review workflow runs sharing the PR's concurrency group all completed with conclusion=failure, 0 jobs, ~3s duration (queued-out rather than cleanly cancelled): Ponytail Reviewer (run 37149784080), Matt Pocock Skills Reviewer (37149784069), PR Code Quality Reviewer (37149784175), Design Decision Gate (37149784070), Test Quality Sentinel (37149784101). Confirmed via get_workflow_jobs: total_count: 0 for these runs — they never even appear as PR check runs, just fleet-wide false-failure noise.

Expected Impact

Fixing this removes a recurring, fleet-wide source of spurious "failure" runs (0 jobs, no check-run) across ~33 workflows whenever a PR gets multiple quick pushes — reducing CI noise and false-positive signals for on-call/triage automation that counts failures.

Suggested Fix

shouldEnableCancelInProgress / isCommandTrigger detection should check whether pull_request is also present among the workflow's triggers and, if so, still enable cancel-in-progress for the natural PR-event path (or split the concurrency group so slash-command invocations and pull_request-event invocations don't share one knob).

Suggested Agent

An agent familiar with the pkg/workflow compiler internals (see .github/skills/developer-internals/SKILL.md).

Estimated Effort

Medium (1-4 hours) — fix plus a regression test in concurrency_test.go covering a mixed pull_request + slash_command workflow.

Data Source

DeepReport analysis — fleet log sample 2026-10-03T19:08-19:51Z (60 runs via agenticworkflows logs), cross-checked via gh-aw compile --debug on ponytail-reviewer.md vs impeccable-skills-reviewer.md.

Generated by 🔬 Deep Report · claude · agent · 548.3 AIC · ⌖ 12.8 AIC · ⊞ 7.1K · ◷

• expires on Oct 5, 2026, 5:48 PM UTC-08:00