[Fleet Monitor] petry-projects/ContentTwin — .github/workflows/pr-review-mention.yml #333

Activity

1. don-petry

   added

   dev-leadFor dev-lead agent pickupFor dev-lead agent pickup

   fleet-trackerTracked by the Actions Fleet MonitorTracked by the Actions Fleet Monitor

   health-checkAutomated health check resultAutomated health check result

   on Jul 14, 2026
2. don-petry commented on Jul 14, 2026

   

   don-petry

   on Jul 14, 2026

   ContributorAuthor

   More actions

   Dev-Lead Implementation Plan

   Issue: #333 — [Fleet Monitor] petry-projects/ContentTwin — .github/workflows/pr-review-mention.yml

   Root cause

   All 43 monitored failures are startup failures (0 jobs, no billable compute), and every one is an issue_comment event. Over a 300-run sample they cluster into a single ~90-second burst (2026-07-14 01:39–01:40 UTC) of ~42 comments posted on one non-PR issue ("ContentTwin Audit"). Outside that burst there are essentially zero failures — normal runs skip cleanly via the reusable's job-level if:.

   The burst runs share one concurrency group (github.workflow + issue number). The local concurrency block added in #323 uses cancel-in-progress: true; when it supersedes a pending reusable-caller run (before the reusable resolves), GitHub records the cancellation as a startup failure, not as a clean cancelled. That is what inflates the Fleet Monitor failure rate.

   Empirical confirmation: the sibling add-to-project.yml, fixed in #331 with cancel-in-progress: false + an event_name-keyed group, records superseded burst runs as cancelled (36/129) with only 2.3% failure — healthy. The org canonical pr-review-mention.yml template carries no concurrency at all; the block here is a local divergence.

   Scope

   Align the concurrency block to the org's validated add-to-project (#331) pattern — cancel-in-progress: false with a group keyed on github.event_name and the issue/PR number — so superseded burst runs are recorded as cancelled instead of startup-failing, without touching the pinned uses: ref, triggers, or permissions.

   Implementation Checklist

   • .github/workflows/pr-review-mention.yml — set cancel-in-progress: false and key the concurrency group on github.event_name + issue/PR number; refresh the rationale comment (reference [Fleet Monitor] petry-projects/ContentTwin — .github/workflows/pr-review-mention.yml #333)

   Tests to Write

   • scripts/tests/pr-review-mention-workflow.bats — flip the "cancels in-progress runs" guard to assert cancel-in-progress is false; assert the group keys on github.event_name as well as issue/PR number; refresh header rationale. Leave the trigger-immutability and stable-channel-delegation guards untouched.

   Test Command

   bats scripts/tests/
3. don-petry commented on Jul 14, 2026

   

   don-petry

   on Jul 14, 2026

   ContributorAuthor

   More actions

   Dev-Lead: Implementation Complete

   Root cause (confirmed from run history)

   Every monitored failure was a startup failure — 0 jobs, no billable compute — and all were issue_comment events. Across a 300-run sample the 42 failures clustered into a single ~90-second burst (2026-07-14 01:39–01:40 UTC) of comments posted on one non-PR issue; outside that burst the workflow is essentially failure-free (normal runs skip cleanly via the reusable's job-level if:).

   Those burst runs all shared one concurrency group. The local block added in #323 used cancel-in-progress: true; superseding a pending reusable-caller run (before the reusable resolves) makes GitHub record the cancellation as a startup failure, not a clean cancelled — inflating the Fleet Monitor failure rate.

   Sibling add-to-project.yml, fixed in #331 with cancel-in-progress: false, records superseded burst runs as cancelled (36/129 in its history) with only 2.3% failure — healthy. This fix ports that validated pattern.

   Plan Execution

   • Diagnosed via gh run list / API: 42/42 failures are 0-job startup failures in one comment burst
   • Confirmed the org canonical pr-review-mention.yml carries no concurrency (the block here is a local [Fleet Monitor] petry-projects/ContentTwin — .github/workflows/pr-review-mention.yml #323 divergence)
   • TDD: updated pr-review-mention-workflow.bats to require cancel-in-progress: false + github.event_name-keyed group (red)
   • Reworked the concurrency block to mirror add-to-project.yml (feat: implement issue #330 — [Fleet Monitor] petry-projects/ContentTwin — .github/workflows/add-to-project.yml #331) (green)
   • Full bats suite + dev-lead-lint.sh pass

   Test Results

   $ bats scripts/tests/pr-review-mention-workflow.bats
   1..7
   ok 1 pr-review-mention workflow file exists
   ok 2 pr-review-mention workflow is valid YAML
   ok 3 pr-review-mention workflow declares a concurrency block
   ok 4 pr-review-mention concurrency does not cancel in-progress runs
   ok 5 pr-review-mention concurrency group is keyed per event and conversation
   ok 6 pr-review-mention triggers are unchanged (stub must not alter events)
   ok 7 pr-review-mention still delegates to the org reusable at the stable channel
   
   $ bats scripts/tests/          # full suite
   52 tests, 0 failures
   
   $ bash .dev-lead/scripts/dev-lead-lint.sh
     [lint] shellcheck on 2 file(s)...
     [lint] validating .github/CODEOWNERS... OK
     [lint] all checks passed
   

   Files Changed

   • .github/workflows/pr-review-mention.yml: cancel-in-progress: true → false; concurrency group re-keyed on github.event_name + issue/PR number (mirrors add-to-project feat: implement issue #330 — [Fleet Monitor] petry-projects/ContentTwin — .github/workflows/add-to-project.yml #331); refreshed rationale comment. The pinned uses: ref, trigger events, and job-level permissions: block are untouched.
   • scripts/tests/pr-review-mention-workflow.bats: flipped the cancel-in-progress guard to assert false, added a github.event_name group-key assertion, and refreshed the header rationale. Trigger-immutability and stable-channel-delegation guards left intact.

   Notes

   • Trade-off is intentional and matches org precedent: superseded burst runs now surface as cancelled (not counted against the failure-rate threshold) rather than as startup failure. add-to-project.yml runs healthy under the same pattern.
   • Two pre-existing tests were updated because they encoded the disproven [Fleet Monitor] petry-projects/ContentTwin — .github/workflows/pr-review-mention.yml #323 hypothesis (cancel-in-progress: true); they were re-pointed at the corrected behavior, not weakened — both fail against the old file and pass against the new one.
   • No shell scripts changed, so the shellcheck/shfmt CI jobs are unaffected.
4. don-petry

   closed this as completedin #336on Jul 14, 2026
5. don-petry

   added a commit that references this issue on Jul 14, 2026

   feat: implement issue #333 — [Fleet Monitor] petry-projects/ContentTw…

   ...

   f2ff479