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

internal/run: TestAParkedRootsRunReviewsItsChildBeforeItAnswers fails 100% of the time on one processor

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

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
68/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
go
Área
devtools, testing-qa

Línea de trabajo

Run GOMAXPROCS=1 go test -count=1 -run '^TestAParkedRootsRunReviewsItsChildBeforeItAnswers$' ./internal/run/, then inspect internal/run/run.go and internal/run/review_order_test.go, especially Supervisor.Run, releaseStale, passInterval, and parkedRootWorker. Determine whether the supervisor or test scripting causes the ordering failure; done means the pinned and GOMAXPROCS=4 package tests pass without branching on processor count.

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

Descripción

area:tests bug sev:papercut

What happened

internal/run went red on two full gate runs, five hours apart, on changes to internal/session. Both times the same test, the same line, the same message, in under half a second:

--- FAIL: TestAParkedRootsRunReviewsItsChildBeforeItAnswers (0.41s)
    review_order_test.go:97: outcome = "ran and did not finish", want "done"

The first sighting was at 8b682938d (0.49s) and was cleared with a rerun. The second was at ec9b01cb0 (0.41s), 106 packages ok, one FAIL, load 4.9 at the end of the run.

It was taken for a flake, and it is not one. It fails 100% of the time when the process has a single processor, and has never been seen with two or more.

Measured 2026-09-20 on two heads, 1a692da6e (the base) and ec9b01cb0 (the base plus one change to internal/session), with prebuilt test binaries so nothing came from a build cache, the two arms interleaved run by run so any drift on the box fell on both equally:

Condition 1a692da6e ec9b01cb0
single test, unconstrained 0/20 0/20
whole package, unconstrained 0/8 0/8
single test, GOMAXPROCS=1 30/30 30/30
single test, GOMAXPROCS=2 0/30 0/30
single test, GOMAXPROCS=4 0/30 0/30
whole package, GOMAXPROCS=1 exit 1, this test only exit 1, this test only
-race, whole package, ×2 pass, 0 data races pass, 0 data races

Every one of the 60 failures is byte-identical to the two gate sightings, between 0.36s and 0.39s. The sibling test in the same file, TestARunningRootsFinishDoesNotCloseTheRunOverAnUnreviewedChild, passes at one processor and at two.

The sub-half-second duration is the part that rules out starvation: the test runs under a 30 second context, so a starved box would show as a timeout near 30 seconds, not as a wrong outcome in 380ms. This is an ordering result.

Replication

Deterministic (no model). One command, no keys, no fixtures, about a second:

GOMAXPROCS=1 go test -count=1 -run '^TestAParkedRootsRunReviewsItsChildBeforeItAnswers$' ./internal/run/

Today that prints the block quoted above and exits 1, every time. The control is the same command with GOMAXPROCS=2, which passes every time.

Field (real models). None. No provider, no key and no model is involved; the test scripts its workers.

Where

internal/run/run.go. Supervisor.Run is the loop that answers the outcome, and OutcomeIncomplete is the constant whose text is ran and did not finish. The scenario is in internal/run/review_order_test.go: the supervisor is built with two slots and the test forces an ordering with childDone and lateTried, with no sleeps, so a root parks on its child while a round its worker had already started still ends its tool.

Searchable strings: OutcomeIncomplete, func (s *Supervisor) Run, releaseStale, passInterval, parkedRootWorker.

What has not been established: which line assumes a second processor, and therefore whether the defect is in the supervisor or in the test's own scripting. The scheduling story below is consistent with everything measured and is not proof of a mechanism.

The fix

A run's answer must not depend on how many processors the process was given. Supervisor.Run should answer done for this scripted order on one processor exactly as it does on two, or, if the test is asserting an order the supervisor never promised, the test should assert the promise it actually makes and say so.

Whichever it is, the outcome is decided by the same constants today and no person-facing wording changes, so no manual page is owed by this fix unless the outcome a run reports changes, which it should not.

Acceptance

  • e2e: GOMAXPROCS=1 go test -count=1 ./internal/run/ exits 0, with no --- FAIL line for TestAParkedRootsRunReviewsItsChildBeforeItAnswers. This is the command that fails today.
  • e2e: the control, GOMAXPROCS=4 go test -count=1 ./internal/run/, still exits 0, so the fix does not trade one parallelism for another.
  • Unit: the scenario pins its own parallelism rather than inheriting the runner's — the test sets runtime.GOMAXPROCS(1) for its own duration and restores it — so the guarantee is that the run answers done on one processor, asserted in the test itself and not dependent on how the gate happens to be configured. Without this the fix is provable only by remembering to pass an environment variable, which is a regression test that can silently stop checking.
  • And the fix does not read the processor count. Nothing in internal/run may branch on runtime.GOMAXPROCS or runtime.NumCPU to satisfy the line above. That branch is the cheapest way to make a pinned scenario pass while leaving the ordering assumption in place for every machine that behaves like one processor under load — which, on the reading above, is how this reached two gates. The shape that counts: the pinned scenario passes, the unconstrained runs keep passing, and the diff contains no read of the processor count.

Two open questions, neither answered here

What parallelism does the gate run under? If a full check runs unconstrained on a many-core box, then two sightings in roughly a dozen full runs is not explained by this result, and the story that load transiently narrows effective parallelism is doing a lot of work. If the gate constrains GOMAXPROCS, the explanation is straightforward. This was not checked.

A lock reading on the test box does not mean the box is quiet. While these runs were taken, two suites were running from other rigs (go test ./internal/tui3 and go test ./internal/session) and the suite flock read FREE throughout, because runs inside cell sandboxes do not take it. Load stayed between 3.2 and 5.6 for the whole experiment. That does not affect this result — 60/60 against 0/120 is not a load effect — but a reader should not take "the lock was free" as "nothing else was running" on this box.

Lenguaje dominante
Go
Estrellas
115
Forks
14
Merge medio
9 h 35 min
PR fusionados (30 d)
752

Preparar el entorno

Aún no hemos revisado los archivos de configuración de este proyecto. Empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

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 Agent-Field/CodeAF

Todos los issues de Agent-Field/CodeAF

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.