Feature request: force-rerun semantic for workflow_dispatch against the same bound issue #22585
Description
Feature request
When a workflow_dispatch run partially fails and an operator re-dispatches against the same issue_number, prior-run state (repo-memory, summary comments on the bound issue, or both) can cause the agent to conclude the work is already done and emit a noop. There is no mechanism to force a fresh evaluation.
This is a feature request for an explicit force-rerun semantic, not a bug report about any single component.
Observed behavior
Repo: Aurrin-Ventures/aurrin-platform, workflow: prd-decomposer, gh-aw v0.62.5, engine: copilot (gpt-5).
| Run | Input | Outcome |
|---|---|---|
| 1 | issue_number=5 |
17/19 issues created. 2 failed (temp ID validation). Summary comment posted on #5. Run: failure. |
| 2 | issue_number=5 |
Closed child issues from run 1. Repo-memory still present. Agent: "Previous decomposition remains in place." 0 issues created. Run: success. |
| 3 | issue_number=5 |
Deleted memory/prd-decomposer. Agent still produced no output, only missing_tool. 0 issues created. Run: success. |
| 4 | issue_number=28 |
Fresh issue (same body, no prior comments) + cleared memory. Clean rerun succeeded. |
Key: deleting the memory branch alone was not enough (run 3). A clean rerun required a fresh issue with no prior comments and cleared memory branches.
Impact
- Re-dispatching against a partially failed issue silently produces no work
- Operators must create a fresh issue to recover, fragmenting the conversation
workflow_dispatch issue_number=Ndoes not override prior-run state strongly enough to force a fresh pass
Relation to existing issues
- workflow_dispatch targeted issue binding ignored — agent never reads bound issue, emits noop, workflow succeeds #21501 (closed): targeted dispatch binding was ignored entirely — adjacent but different. The behavior here was observed on v0.62.5 after that fix shipped. Don Syme characterized workflow_dispatch targeted issue binding ignored — agent never reads bound issue, emits noop, workflow succeeds #21501 as mostly a prompting issue.
- ${{ steps.sanitized.outputs.text }} appears in generated prompt #21624 (closed): template variable leak in generated prompt — does not cover rerun semantics or persisted prior-run state.
- Targeted dispatch can drift into scheduled backlog triage when bound issues are integrity-filtered on public repos #21784 (open): targeted dispatch can drift when hidden state interferes — related in spirit but covers integrity-filtered dispatch drift, not same-issue reruns.
None of these cover the case where the agent does read the bound issue but concludes the work is already done based on prior-run artifacts.
Suggested approaches
-
Explicit force-rerun flag: a
workflow_dispatchinput or workflow-level config (e.g.force_fresh: true) that tells the agent to recompute from current repo state, ignoring prior completion signals for this issue. -
Run-aware context handling: tag repo-memory entries and safe-output comments with run metadata so prior-run summaries aren't treated as authoritative for new runs.
-
Noop rejection guardrail: reject a
successnoop if the bound issue was never meaningfully re-evaluated in the current run — the scout report on workflow_dispatch targeted issue binding ignored — agent never reads bound issue, emits noop, workflow succeeds #21501 also identified this missing guard.
Environment
- gh-aw: v0.62.5
- Engine: copilot (gpt-5)
- Workflow: prd-decomposer