What happened
During PR #6239's lifecycle, the ready-for-merge label was added at 21:57 UTC. The fullsend.yaml shim's condition uses startsWith(github.event.label.name, 'ready-') to filter labeled events, which matched ready-for-merge. This triggered a shim run on the source repo (run on fullsend-ai/fullsend) which dispatched to fullsend-ai/.fullsend, where dispatch.yml found no matching stage for this label and exited with "no stage matched." The same pattern also occurred for the unlabeled event when requires-manual-review was removed — the shim has no guard against unlabeled events passing through.
In total, ~2–3 shim+dispatch chains ran to empty no-op outcomes due to labels that pass the prefix filter but have no dispatch route. Each chain burns ~2 runner-minutes (one in the source repo, one in .fullsend).
What could go better
The startsWith('ready-') prefix filter is a loose approximation of the actual dispatch routing table. dispatch.yml only routes ready-for-review (to review) and ready-to-code (to code), but the prefix also admits ready-for-merge and any future ready-* labels. This creates a steady trickle of wasted runner-minutes across all enrolled repos.
This is a high-confidence finding: the mismatch between the shim filter and dispatch routing is mechanical and verifiable from the workflow files. The fix is straightforward. Existing issue #893 covers pull_request_review event filtering but does not address the label prefix filter. No other open issue covers this specific label-filter gap.
Proposed change
In the fullsend.yaml workflow template (used by enrolled repos), replace the broad prefix check with exact label matching. Change the labeled-event condition from:
startsWith(github.event.label.name, 'ready-')
To an exact match against labels that dispatch.yml actually routes:
github.event.label.name == 'ready-for-review' || github.event.label.name == 'ready-to-code'
Also consider adding github.event.action != 'unlabeled' to the condition (or removing unlabeled from pull_request_target.types) since dispatch.yml has no unlabeled handler.
Note: if dispatch routing adds new ready-* labels in the future, both the shim filter and the dispatch table should be updated together — the exact-match approach makes this coupling explicit rather than silently accepting unrouted labels.
Validation criteria
After the change, adding the ready-for-merge label to any PR should not trigger a fullsend.yaml shim run. Verify by checking that no shim workflow runs are created for labeled events with ready-for-merge on the next 3 PRs that receive that label. Also verify that ready-for-review and ready-to-code labels still dispatch correctly.
Generated by retro agent from #6239
What happened
During PR #6239's lifecycle, the
ready-for-mergelabel was added at 21:57 UTC. Thefullsend.yamlshim's condition usesstartsWith(github.event.label.name, 'ready-')to filter labeled events, which matchedready-for-merge. This triggered a shim run on the source repo (run on fullsend-ai/fullsend) which dispatched tofullsend-ai/.fullsend, wheredispatch.ymlfound no matching stage for this label and exited with "no stage matched." The same pattern also occurred for theunlabeledevent whenrequires-manual-reviewwas removed — the shim has no guard againstunlabeledevents passing through.In total, ~2–3 shim+dispatch chains ran to empty no-op outcomes due to labels that pass the prefix filter but have no dispatch route. Each chain burns ~2 runner-minutes (one in the source repo, one in
.fullsend).What could go better
The
startsWith('ready-')prefix filter is a loose approximation of the actual dispatch routing table.dispatch.ymlonly routesready-for-review(to review) andready-to-code(to code), but the prefix also admitsready-for-mergeand any futureready-*labels. This creates a steady trickle of wasted runner-minutes across all enrolled repos.This is a high-confidence finding: the mismatch between the shim filter and dispatch routing is mechanical and verifiable from the workflow files. The fix is straightforward. Existing issue #893 covers
pull_request_reviewevent filtering but does not address the label prefix filter. No other open issue covers this specific label-filter gap.Proposed change
In the
fullsend.yamlworkflow template (used by enrolled repos), replace the broad prefix check with exact label matching. Change the labeled-event condition from:startsWith(github.event.label.name, 'ready-')To an exact match against labels that dispatch.yml actually routes:
github.event.label.name == 'ready-for-review' || github.event.label.name == 'ready-to-code'Also consider adding
github.event.action != 'unlabeled'to the condition (or removingunlabeledfrompull_request_target.types) since dispatch.yml has nounlabeledhandler.Note: if dispatch routing adds new
ready-*labels in the future, both the shim filter and the dispatch table should be updated together — the exact-match approach makes this coupling explicit rather than silently accepting unrouted labels.Validation criteria
After the change, adding the
ready-for-mergelabel to any PR should not trigger afullsend.yamlshim run. Verify by checking that no shim workflow runs are created forlabeledevents withready-for-mergeon the next 3 PRs that receive that label. Also verify thatready-for-reviewandready-to-codelabels still dispatch correctly.Generated by retro agent from #6239