What happened
Two code agent workflow runs were dispatched for issue #239 within 38 seconds: run 29010929584 (created 10:14:14, cancelled at 10:15:03 after 30 seconds of sandbox creation) and run 29010964798 (created 10:14:52, succeeded). The triage run 29010690405 completed at 10:13:55. A second triage run (29011167811, for a different issue) started at 10:18:32. The cancelled code run consumed compute resources for sandbox setup but no LLM token cost.
What could go better
A concurrency guard or dedup check at dispatch time would have prevented the second code run from starting. The compute waste was minor (30 seconds of sandbox creation), but in higher-volume repos this pattern could compound. Medium confidence this was a dispatch race rather than a deliberate retry, since both runs were for the same issue and the cancelled run had no meaningful progress.
Proposed change
Add this as evidence for issue #766 (dispatch-layer dedup and per-issue concurrency guard). The conforma org is newly onboarded and already exhibiting the duplicate dispatch pattern, confirming the issue is not org-specific. The fix in #766 should include a check at dispatch time that no other code agent run is in-progress for the same issue number.
Validation criteria
After #766 is implemented, verify that only one code agent run is dispatched per issue per triage event. The cancelled-run-followed-by-successful-run pattern should not recur.
Generated by retro agent from conforma/user-guide#241
What happened
Two code agent workflow runs were dispatched for issue #239 within 38 seconds: run 29010929584 (created 10:14:14, cancelled at 10:15:03 after 30 seconds of sandbox creation) and run 29010964798 (created 10:14:52, succeeded). The triage run 29010690405 completed at 10:13:55. A second triage run (29011167811, for a different issue) started at 10:18:32. The cancelled code run consumed compute resources for sandbox setup but no LLM token cost.
What could go better
A concurrency guard or dedup check at dispatch time would have prevented the second code run from starting. The compute waste was minor (30 seconds of sandbox creation), but in higher-volume repos this pattern could compound. Medium confidence this was a dispatch race rather than a deliberate retry, since both runs were for the same issue and the cancelled run had no meaningful progress.
Proposed change
Add this as evidence for issue #766 (dispatch-layer dedup and per-issue concurrency guard). The conforma org is newly onboarded and already exhibiting the duplicate dispatch pattern, confirming the issue is not org-specific. The fix in #766 should include a check at dispatch time that no other code agent run is in-progress for the same issue number.
Validation criteria
After #766 is implemented, verify that only one code agent run is dispatched per issue per triage event. The cancelled-run-followed-by-successful-run pattern should not recur.
Generated by retro agent from conforma/user-guide#241