Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

fix(review): pin ordinary commit and range inputs before loading diffs

Ouverte
  • Quelque chose ne va pas ?
#1,663 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@Dante-dan y travaille déjà.

Depuis le 7/10/2026.

  • #1664 par @Dante-dan — ouverte

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
50/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
git, go
Domaine
backend, devtools

Piste de recherche

Start by tracing validateResumeIdentity, Provider.GetDiffSet, ParseDiffText, and Agent.loadDiffs, along with the existing endpoint-resolution and Args.SealedInput machinery. Add focused regression tests that move a ref between admission and diff/content loading and verify consistent resolved head and content for Commit and Range, plus workspace and invalid-ref behavior. Run make check, make test, make build, and OCR self-review; report which checks were actually completed.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Problem

Ordinary non-resume Commit/Range reviews can read different commits within a single input when a named Git ref moves during the review. This follows the first question in Discussion #1658; the separate Resume duplicate-computation proposal is outside this issue.

At main 182898cf522da3d04157b422752d028417974e19:

  1. validateResumeIdentity returns no sealed input when no resume state exists.
  2. Provider.GetDiffSet obtains the diff using the original --to/--commit ref, then ParseDiffText reads each changed file through that same mutable ref.
  3. Agent.loadDiffs resolves manifest endpoints after obtaining the diff.

For ocr review --from main --to feature, moving feature from B to C after the diff command can therefore pair an A→B patch with C's NewFileContent or record C as the manifest head. --commit HEAD has the same window. This report is based on current code-path analysis, not a reproduced occurrence in a running LLM review.

Expected behavior

The patch, complete changed-file content, recorded resolved endpoints, and commit-backed tool reads should refer to the same immutable input for the run. Workspace review should retain its current live-working-tree behavior.

Proposed narrow fix

Resolve ordinary Commit/Range endpoints before loading a diff, reusing the existing endpoint-resolution and Args.SealedInput machinery. Carry one resolution through the existing diff provider and reader construction without introducing another diff/selection pass. Preserve original user ref strings as requested-input metadata; reject an unresolvable endpoint before creating a session. Leave Resume reuse/computation and fetching out of scope.

Related work: #1586 seals the endpoints of the opt-in --fetch path and explicitly retains existing behavior without --fetch; this issue concerns default non-fetch reviews. #1627 pins the shared tool reader after diff loading for corrective-read evidence; it does not pin the diff/full-content/manifest inputs before loading. This proposal should reuse compatible endpoint plumbing rather than duplicate either feature.

Validation plan

Add focused repository regression coverage that moves a ref between admission and diff/content loading, asserts consistent resolved head/content for Commit and Range, and covers workspace and invalid-ref behavior. Run the repository-required make check, make test, make build, and OCR self-review; report actual results and unperformed checks.

Environment

  • Version: source snapshot at main 182898cf522da3d04157b422752d028417974e19; no installed release was used for the code-path analysis.
  • OS: macOS, arm64.
  • Installation method: source checkout inspected locally; no CLI installation was used for this report.
  • LLM provider: not applicable; the finding is in Git input preparation before any model call.

Steps / race schedule

This is the concrete schedule supported by the code, not a claimed executed end-to-end reproduction:

  1. Start a non-resume range review using moving refs, such as ocr review --from main --to feature, where feature points at B.
  2. Allow the provider to generate git diff <merge-base> feature while feature still points at B.
  3. Move feature to C before the per-file git show feature:<path> or later ResolveInput operation.
  4. The original patch describes B, while complete file content or the recorded resolved head can describe C. The analogous commit case uses ocr review --commit HEAD and moves HEAD in the same interval.

Workaround: pass full commit SHAs for endpoints. No runtime logs are attached because a running LLM review has not been reproduced.

AI assistance

Codex with GPT-6.1-sol performed the code-path analysis and prepared this proposal; GPT-6-luna gathered the current discussion, contribution rules, and related implementation evidence.

Langage dominant
Go
Étoiles
47.7k
Forks
3.5k
Merge moyen
3 j 13 h
PR mergées (30 j)
38

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de alibaba/open-code-review

Toutes les issues de alibaba/open-code-review

Issues similaires

Plus d'issues Go

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.