Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Dynamic Review: leave a short failure note on the pull request when a run fails

Chiusa
  • Qualcosa non va?
#299 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Una pull request collegata è già stata integrata.

  • #315 di @Schacki-Jr — integrata

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
backend, documentation, testing

Direzione di ricerca

Start with the Dynamic run failure path in the runner and the publisher code that owns the persistent Dynamic summary comment, then find where the stable failure codes from #296 are defined. Add a note for the listed codes that holds only a fixed sentence, the code, the reason and the head SHA, with a table test that fails when a code has no sentence. Done when T01 to T08 pass, the do-not-write codes write nothing, and docs/dynamic-review.md (T10) describes the note and its update rules.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

area: runner type: feature

Follows #296 (stable failure reasons for the Dynamic Review checkout).

Problem

When a Dynamic run fails, nothing appears on the pull request. The developer sees silence: no comment, no check, and the reason is only visible to someone who can open the Runs view. A failed run should say, briefly and safely, that it failed and why.

Design

  • A short failure note on the pull request. When a Dynamic run ends in a failure that the developer can understand or act on, the runner writes one short note into the run's own Dynamic summary comment (the comment the publisher already owns), so there is never a second comment. The note says that the Dynamic Review did not complete, names the stable error code and, where the run has one, the stable reason (for example checkout_incomplete / budget_preparation) and gives one fixed sentence per code from a table in the code (the same copy rule as the Runs view: the code is translated to words, never the other way round).
  • No repository content. The note holds only fixed sentences, the code, the reason and the head SHA. No path, file name, diff text, log line, model output or provider message. A test asserts that a failure whose log holds repository text, a secret or a path produces a note without any of it.
  • Update, do not spam. The note lives in the same persistent summary comment as a successful review. A repeated failure on the same head replaces the note instead of adding another; a later successful run replaces it with the review; a failure never overwrites the findings of an earlier successful review on that PR beyond adding or refreshing the note (the earlier findings stay).
  • Which failures. Codes that are about the run itself and the repository (checkout_incomplete, dynamic_budget_exceeded, dynamic_model_features_unsupported, llm_* provider failures, timeout) write a note. Failures where the runner cannot write safely (lease_lost, a lost token, git_auth, git_forbidden) write nothing and stay visible in the Runs view only.
  • Fail closed. If writing the note itself fails, the run keeps its original failure code; the note never changes the verdict.

Test cases

ID kind level case expected
T01 behavior unit (publish) a Dynamic run fails with checkout_incomplete and a reason the summary comment gets a note with the code, the reason and the fixed sentence
T02 security unit (publish) the failure log holds a path, a diff line, a model message and a secret the note holds none of them; only fixed text, code, reason and head SHA
T03 behavior unit (publish) the same failure repeats on the same head the existing comment is updated; no second comment is created
T04 behavior unit (publish) a later run succeeds the note is replaced by the review
T05 behavior unit (publish) a failure after an earlier successful review the earlier findings stay in the comment; the note is added or refreshed
T06 behavior unit (runner) a code on the do-not-write list (lease_lost, git_auth) nothing is written
T07 behavior unit (runner) writing the note fails the run keeps its original failure code and reason
T08 behavior unit (publish) every code with a note has a sentence a table test fails when a new code has none
T09 regression engine (real OpenCode, fake GitHub) a Dynamic E2E run whose checkout fails one comment with the note exists on the fake pull request
T10 docs review docs/dynamic-review.md the note, its content rules and the update behaviour are documented
Lingua principale
TypeScript
Stelle
0
Fork
1
Merge medio
1h 15m
PR unite (30g)
217

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ExpidetGames/code-reviewer

Tutte le issue di ExpidetGames/code-reviewer

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.