Skip to content

fix(triage): classify maintainer revision requests as rejected, not inconclusive - #61

Merged
matthewp merged 1 commit into
mainfrom
fix/fix-verifier-maintainer-feedback
Nov 3, 2026
Merged

matthewp merged 1 commit into
mainfrom
fix/fix-verifier-maintainer-feedback

Conversation

@matthewp

@matthewp matthewp commented Nov 3, 2026

Copy link
Copy Markdown
Contributor

What

Broaden FixVerifier's negative-confirmation definition to cover a maintainer (or anyone with technical authority) reviewing the candidate fix's diff and asking for it to be revised/simplified, or explicitly requesting a retriage — even when they confirm the approach technically works.

Why

FixVerifier's prompt only described reporter confirm/deny semantics ("does the preview release fix your issue"). On withastro/astro#18590, a maintainer reviewed the diff, confirmed the diagnosis and that the fix passes tests, but asked for a simpler implementation and explicitly said "please retriage with the simpler fix." That comment matched neither the positive nor negative examples, so it fell into inconclusive — which the workflow handles by doing nothing: no label change, no comment, no retriage. From the outside it looked like the bot ignored the comment entirely.

This is the same class of bug fixed in #60 (silent no-op on a verdict that actually carries actionable feedback), just hitting the inconclusive bucket of the classifier instead of rejected.

How

  • Added explicit guidance to the FixVerifier prompt: a maintainer-authority revision request or an explicit retriage request is a negative confirmation, not inconclusive.
  • No workflow changes needed — rejected already chains straight into retriage() with the full conversation (from fix(triage): chain rejected fixes straight into retriage #60), so once classified correctly the maintainer's simpler-fix suggestion reaches a fresh triage attempt.

Testing

  • tsc --noEmit clean.
  • vitest run: 459/459 pass.

…nconclusive

FixVerifier's prompt only described reporter confirm/deny semantics
('does the fix resolve the issue for you'). A maintainer reviewing the
diff itself -- confirming the fix technically works but asking for a
simpler implementation and an explicit retriage -- didn't match either
the positive or negative examples, so it fell into 'inconclusive',
which the workflow handles by silently doing nothing: no label change,
no comment, no retriage (see withastro/astro#18590).

Broaden the negative-confirmation definition to cover a maintainer (or
anyone with technical authority) asking for the candidate fix to be
revised or redone, or explicitly requesting a retriage, even when they
say the approach otherwise works. That verdict now chains into
retriage() (per the earlier fix for #18600), so feedback like this
reaches a fresh triage attempt instead of disappearing.
@matthewp
matthewp merged commit f9bb84d into main Nov 3, 2026
1 check passed
@matthewp
matthewp deleted the fix/fix-verifier-maintainer-feedback branch November 3, 2026 15:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant