Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#1,663 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@Dante-dan ya está trabajando en esto.

Desde el 7/10/2026.

  • #1664 de @Dante-dan — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
50/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
git, go
Área
backend, devtools

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Go
Estrellas
46.9k
Forks
3.4k
Merge medio
3 d 1 h
PR fusionados (30 d)
41

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de alibaba/open-code-review

Todos los issues de alibaba/open-code-review

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.