fix(pr-status): name a request-review that waiting cannot clear - #169
Conversation
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
`--watch` exits on request-review, which is right while a review can still arrive. When the bot has failed twice on the head it cannot: a quota ceiling does not clear by waiting, so every re-arm of the watch returns instantly with the same line and the operator learns nothing from the second one. The script already knows this state — copilot_error_count >= 2 is what selects the "do not keep re-requesting" advice — it just did not say so at the point where the decision to re-arm is made. It does now, and it names the watch that does move instead: gh pr checks --watch. Found in a session that re-armed this watch three times before switching instrument by hand. Signed-off-by: Sebastian Mendel <github@sebastianmendel.de>
ad976ba to
f796fff
Compare
|
|
Copilot failed twice on f796fff, so read by hand — which is, fittingly, exactly the state this change teaches the watcher to name. The diff splits Checked: Recorded plainly: no human has read this. |
--watchexits onrequest-review, which is correct while a review can still arrive. Once the bot has failed twice on the head it cannot — a quota ceiling does not clear by waiting — so every re-arm returns instantly with the same line, and the second one teaches the operator nothing.The script already distinguishes that state:
copilot_error_count >= 2is what selects the do not keep re-requesting advice. It simply did not surface it at the moment the operator decides whether to re-arm. Now the ACTIONABLE line says the state is unsatisfiable and names the watch that does move:Found the hard way: a session re-armed this watch three times before switching instrument by hand.
Verified with
bash -nand by running the changed script against a live PR — the non-exhausted paths are untouched (the run took thecheck failedbranch).Came from /retro: yes.