What happened
When /fs-triage was invoked on issues #65, #66, and #67 in agentshed/seshi PR #69, each issue generated multiple workflow runs. The triage agent applied labels (e.g., ready-to-code, bug, tui), and each label addition fired a new issues: labeled event, re-triggering the fullsend.yaml workflow. Across 3 issues, this produced 15 workflow runs where only 3 were necessary. 6 runs were cancelled as duplicates by GitHub's queue management, and the remaining extra runs executed only the lightweight Route job (~5-6 seconds each) before discovering there was nothing to do.
What could go better
The fullsend.yaml workflow triggers on issues: [opened, edited, labeled] without filtering by sender type. When the triage bot applies labels, this creates a feedback loop of unnecessary runs. The existing concurrency controls (cancel-in-progress: false grouped by issue number) queue these runs rather than dropping them. While actual compute waste is under 1 minute, the noise in the Actions tab makes it harder to find meaningful runs. Confidence: High — this is a straightforward event-filtering issue observable across all repos using the standard fullsend.yaml template.
Proposed change
In the fullsend.yaml workflow template (or its generation logic in fullsend-ai/fullsend), add a condition to skip runs triggered by bot-applied labels. Two options:
-
Filter by sender type on the labeled event: add a job-level condition like if: github.event.action != 'labeled' || github.actor_type != 'Bot' (or check github.event.sender.type != 'Bot').
-
Set cancel-in-progress: true on the concurrency group for issue events, since the Route job is idempotent and agent stages are skipped for label-only events anyway.
Option 1 is preferred as it prevents the runs from starting at all, while option 2 reduces queue depth but still consumes runner startup time.
Validation criteria
After the change is deployed, trigger /fs-triage on a repo with 3+ issues in a batch. The number of workflow runs per issue should drop from ~5 to ~2 (the initial triage dispatch + at most one label event). No cancelled runs should appear from bot-applied label events.
Generated by retro agent from agentshed/seshi#69
What happened
When
/fs-triagewas invoked on issues #65, #66, and #67 in agentshed/seshi PR #69, each issue generated multiple workflow runs. The triage agent applied labels (e.g.,ready-to-code,bug,tui), and each label addition fired a newissues: labeledevent, re-triggering thefullsend.yamlworkflow. Across 3 issues, this produced 15 workflow runs where only 3 were necessary. 6 runs were cancelled as duplicates by GitHub's queue management, and the remaining extra runs executed only the lightweight Route job (~5-6 seconds each) before discovering there was nothing to do.What could go better
The
fullsend.yamlworkflow triggers onissues: [opened, edited, labeled]without filtering by sender type. When the triage bot applies labels, this creates a feedback loop of unnecessary runs. The existing concurrency controls (cancel-in-progress: falsegrouped by issue number) queue these runs rather than dropping them. While actual compute waste is under 1 minute, the noise in the Actions tab makes it harder to find meaningful runs. Confidence: High — this is a straightforward event-filtering issue observable across all repos using the standard fullsend.yaml template.Proposed change
In the fullsend.yaml workflow template (or its generation logic in fullsend-ai/fullsend), add a condition to skip runs triggered by bot-applied labels. Two options:
Filter by sender type on the
labeledevent: add a job-level condition likeif: github.event.action != 'labeled' || github.actor_type != 'Bot'(or checkgithub.event.sender.type != 'Bot').Set
cancel-in-progress: trueon the concurrency group for issue events, since the Route job is idempotent and agent stages are skipped for label-only events anyway.Option 1 is preferred as it prevents the runs from starting at all, while option 2 reduces queue depth but still consumes runner startup time.
Validation criteria
After the change is deployed, trigger
/fs-triageon a repo with 3+ issues in a batch. The number of workflow runs per issue should drop from ~5 to ~2 (the initial triage dispatch + at most one label event). Nocancelledruns should appear from bot-applied label events.Generated by retro agent from agentshed/seshi#69