What happened
The konflux-ci org config (config.yaml in .fullsend repo) explicitly comments out #- retro from defaults.roles with a note: 'Retro agent is awesome, but it currently has a bug where it fails to post a comment back on the PR that triggered it. Let's re-enable after this is fixed: #1076'. Issue #1076 (retro post-script permission error) has since been closed, but the config comment was never updated.
More importantly, the commented-out - retro line never had any effect. The dispatch.yml maps retro to the 'fullsend' base role (case retro|prioritize) STAGE_ROLE="fullsend"), and 'fullsend' is always present in defaults.roles. As a result, retro dispatches on every PR close in every enabled repo across the org.
In notification-service alone, retro dispatched on both autoclosed PRs #858 and #860 on 2026-07-11, consuming tokens for zero-value analysis.
What could go better
The org admin's explicit intent to disable retro is being silently ignored. This compounds the waste from other issues (#4006): not only should retro be skipped for certain PR types, but the org-level disable mechanism itself is broken.
PR #4049 (support disabling agents via config.yaml enabled field) may provide a proper mechanism, but the existing role mapping in dispatch.yml should also be corrected so that the roles list semantics work as users expect. An admin commenting out a role should actually disable that stage.
Uncertainty: it is possible the org admins are aware retro runs and have accepted it (since #1076 is fixed), but the stale config comment suggests otherwise.
Proposed change
Fix the dispatch.yml role check to treat retro as its own role rather than mapping it to the fullsend base role. Change the case statement from retro|prioritize) STAGE_ROLE="fullsend" to only prioritize) STAGE_ROLE="fullsend", leaving retro to check against its own entry in the roles list. Additionally, update the konflux-ci org config to either uncomment - retro (if intended to be enabled now that #1076 is fixed) or remove the stale comment referencing the fixed issue.
Validation criteria
When - retro is commented out of defaults.roles in the org config, retro dispatch is actually blocked (the workflow exits with 'Stage retro not in defaults.roles — dispatch blocked'). Verify by checking that PR close events in enrolled repos do not trigger retro workflow runs.
Generated by retro agent from konflux-ci/notification-service#860
What happened
The konflux-ci org config (config.yaml in .fullsend repo) explicitly comments out
#- retrofromdefaults.roleswith a note: 'Retro agent is awesome, but it currently has a bug where it fails to post a comment back on the PR that triggered it. Let's re-enable after this is fixed: #1076'. Issue #1076 (retro post-script permission error) has since been closed, but the config comment was never updated.More importantly, the commented-out
- retroline never had any effect. The dispatch.yml maps retro to the 'fullsend' base role (case retro|prioritize) STAGE_ROLE="fullsend"), and 'fullsend' is always present in defaults.roles. As a result, retro dispatches on every PR close in every enabled repo across the org.In notification-service alone, retro dispatched on both autoclosed PRs #858 and #860 on 2026-07-11, consuming tokens for zero-value analysis.
What could go better
The org admin's explicit intent to disable retro is being silently ignored. This compounds the waste from other issues (#4006): not only should retro be skipped for certain PR types, but the org-level disable mechanism itself is broken.
PR #4049 (support disabling agents via config.yaml enabled field) may provide a proper mechanism, but the existing role mapping in dispatch.yml should also be corrected so that the roles list semantics work as users expect. An admin commenting out a role should actually disable that stage.
Uncertainty: it is possible the org admins are aware retro runs and have accepted it (since #1076 is fixed), but the stale config comment suggests otherwise.
Proposed change
Fix the dispatch.yml role check to treat retro as its own role rather than mapping it to the fullsend base role. Change the case statement from
retro|prioritize) STAGE_ROLE="fullsend"to onlyprioritize) STAGE_ROLE="fullsend", leaving retro to check against its own entry in the roles list. Additionally, update the konflux-ci org config to either uncomment- retro(if intended to be enabled now that #1076 is fixed) or remove the stale comment referencing the fixed issue.Validation criteria
When
- retrois commented out of defaults.roles in the org config, retro dispatch is actually blocked (the workflow exits with 'Stage retro not in defaults.roles — dispatch blocked'). Verify by checking that PR close events in enrolled repos do not trigger retro workflow runs.Generated by retro agent from konflux-ci/notification-service#860