Problem
Adding pdd-clean-restart alongside a command label (e.g. pdd-issue) on an issue that also carries an ordinary bug label fails. The bot posts:
pdd-clean-restart cannot choose between multiple active command labels: bug, pdd-issue. Remove the labels you do not want to restart, then re-apply pdd-clean-restart (the label has been cleared so it can be re-added).
It treats the standard bug label (description "Something isn't working") as a PDD "command label," so it cannot pick a single command to restart, and it clears its own label.
Why this is bad (UX)
Almost every bug-type issue carries a bug (and often cli) label. So the common flow "add pdd-issue + pdd-clean-restart to restart an autonomous run from step 1" nearly always hits this error and fails to restart, defeating the purpose of the modifier ("combine with a command label to restart from step 1"). The user just wants the run to restart cleanly.
Evidence
Occurred on issue #1923 when pdd-issue + pdd-clean-restart were applied together while the issue also had the bug label. The pdd-issue run still created PR #1959, but pdd-clean-restart errored and removed itself, so no clean restart happened.
Expected behavior
pdd-clean-restart should only consider actual PDD command labels (e.g. pdd-issue, pdd-fix, pdd-change, pdd-bug, pdd-generate, pdd-test, pdd-sync, pdd-decompose, pdd-connect, pdd-checkup*) when determining the restart target, and ignore non-PDD labels like bug, cli, enhancement. It should only error when there are genuinely multiple PDD command labels.
Proposed solution
Filter the candidate label set to the known PDD command-label namespace (e.g. labels beginning with pdd- that map to a command, excluding passive modifiers) before deciding ambiguity. Red/green test: an issue labeled bug + pdd-issue + pdd-clean-restart should restart the pdd-issue job from step 1 (not error); an issue with two real command labels (pdd-issue + pdd-fix) should still error.
References
Problem
Adding
pdd-clean-restartalongside a command label (e.g.pdd-issue) on an issue that also carries an ordinarybuglabel fails. The bot posts:It treats the standard
buglabel (description "Something isn't working") as a PDD "command label," so it cannot pick a single command to restart, and it clears its own label.Why this is bad (UX)
Almost every bug-type issue carries a
bug(and oftencli) label. So the common flow "addpdd-issue+pdd-clean-restartto restart an autonomous run from step 1" nearly always hits this error and fails to restart, defeating the purpose of the modifier ("combine with a command label to restart from step 1"). The user just wants the run to restart cleanly.Evidence
Occurred on issue #1923 when
pdd-issue+pdd-clean-restartwere applied together while the issue also had thebuglabel. Thepdd-issuerun still created PR #1959, butpdd-clean-restarterrored and removed itself, so no clean restart happened.Expected behavior
pdd-clean-restartshould only consider actual PDD command labels (e.g.pdd-issue,pdd-fix,pdd-change,pdd-bug,pdd-generate,pdd-test,pdd-sync,pdd-decompose,pdd-connect,pdd-checkup*) when determining the restart target, and ignore non-PDD labels likebug,cli,enhancement. It should only error when there are genuinely multiple PDD command labels.Proposed solution
Filter the candidate label set to the known PDD command-label namespace (e.g. labels beginning with
pdd-that map to a command, excluding passive modifiers) before deciding ambiguity. Red/green test: an issue labeledbug+pdd-issue+pdd-clean-restartshould restart the pdd-issue job from step 1 (not error); an issue with two real command labels (pdd-issue+pdd-fix) should still error.References