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

internal/session: two tests fail only while other suites run beside them — a 40 ms wall-clock audit window, and a write under the home after Close

Abierto
  • ¿Algo no está bien?
#1,491 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
Bien especificado
Estado de actividad
Activo
Stack tecnológico
go
Área
backend, testing-qa

Línea de trabajo

Start with the two named tests in internal/session/task_settle_test.go and internal/session/retiredpin_wire_test.go, then reproduce them under the supplied GOMAXPROCS=2 busy-loop commands. Trace the audit-window behavior and Agent.Close lifecycle, including errand writers under <CODEAF_HOME>/v3. Done means both -count=200 loops pass under load three times, the post-Close home probe finds no late writes, and touched packages remain green without a rerun.

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

Descripción

area:session area:tests

What happened

Two internal/session tests fail only while other test suites run beside them on the same machine. Each passes when run alone. CLAUDE.md treats a failure like this as a bug report rather than a flake to rerun, so here it is. Both were seen during make pr-ready BASE=origin/dev runs for #1410 (santos/dev2) on 2026-09-24, and neither test file is touched by that branch. retiredpin_wire_test.go came to dev with #1108, and task_settle_test.go was last changed on dev in #949.

1. TestAStalledCheckerIsNamedAsAStallEvenWhenItSpentTheWindow (task_settle_test.go):

=== RUN   TestAStalledCheckerIsNamedAsAStallEvenWhenItSpentTheWindow
    task_settle_test.go:315: the report does not say what actually happened to the calls:
        the check ran out of time before a call could be made — it had 40ms
        Wrote greet.go with the greeting.
--- FAIL: TestAStalledCheckerIsNamedAsAStallEvenWhenItSpentTheWindow (0.75s)

The test sets config.auditWindow = 40 * time.Millisecond, a real wall-clock window, and scripts a checker that never answers on either of its two attempts. It expects the report to say the calls were abandoned. On a loaded box the 40 ms ran out before the first checker call was placed, so the report took the other true branch, "ran out of time before a call could be made". The assertion depends on the scheduler, not the code.

2. TestAnErrandBesideTheTurnDoesNotCarryTheTalkPin (retiredpin_wire_test.go):

=== RUN   TestAnErrandBesideTheTurnDoesNotCarryTheTalkPin
    testing.go:1464: TempDir RemoveAll cleanup: unlinkat /tmp/TestAnErrandBesideTheTurnDoesNotCarryTheTalkPin1419077516/001/v3: directory not empty
--- FAIL: TestAnErrandBesideTheTurnDoesNotCarryTheTalkPin (0.01s)

001 is the test's home.EnvVar directory. Something still writes under <home>/v3 after the test's agent.Close() cleanup has returned. The write races t.TempDir's RemoveAll, and it lands inside the removal only when the box is slow. The likely writer is the errand the test name refers to (a side call made beside the turn), or its journal, still running after Close. This is the same late-write-after-close class as #1198 and the cmd/codeaf hosted-welcome test (#1492). #1441 lists other load-only reds on the same branch; these two are not on it.

Replication

Deterministic (no model). Neither needs a key. Load the box, then loop the one test:

# load: one busy loop per core, stopped afterwards with `kill %1 %2 ...` or `pkill -x yes`
for i in $(seq "$(nproc)"); do yes >/dev/null & done
GOMAXPROCS=2 go test -count=200 -run '^TestAStalledCheckerIsNamedAsAStallEvenWhenItSpentTheWindow$' ./internal/session/
GOMAXPROCS=2 go test -count=200 -run '^TestAnErrandBesideTheTurnDoesNotCarryTheTalkPin$' ./internal/session/

Without the load the same loops pass: 20 of 20 and 50 of 50 on both santos/dev2 and its base. The only sightings so far are one failure of each inside a whole make pr-ready (the light gate plus every package the branch touches, internal/session among them, run beside internal/tui3). How often the loaded loop above fails has not been measured yet; the first job of whoever takes this is to get it failing on demand.

Field. Not needed. No model is involved.

Where

  • internal/session/task_settle_test.go, TestAStalledCheckerIsNamedAsAStallEvenWhenItSpentTheWindow. Search for config.auditWindow = 40 * time.Millisecond. The two report sentences are checkerWindowClosed / "without answering and was abandoned" and "ran out of time before a call could be made".
  • internal/session/retiredpin_wire_test.go, TestAnErrandBesideTheTurnDoesNotCarryTheTalkPin, together with whatever Agent.Close leaves running that writes under <CODEAF_HOME>/v3.

The fix

  1. The audit window in that test runs on the test's own clock, or the checker's first call is proven placed before the window is allowed to close, so the test asserts the stall sentence and never the scheduler.
  2. Agent.Close waits for everything it started that writes under the home, errands included, before it returns. This follows the close law #1259 and #1274 set for the process. After Close returns, nothing writes under the home. The test must not be changed to skip the cleanup.

Acceptance

  • Unit (under load): both -count=200 loops above are green with one busy loop per core running, three times in a row.
  • Unit (law): a probe that walks <home> for files modified after agent.Close() returned, after a 2-second wait, finds none for the talk-pin test's agent.
  • touched packages on the next promotion stays green without a rerun.
Lenguaje dominante
Go
Estrellas
115
Forks
14
Merge medio
9 h 38 min
PR fusionados (30 d)
749

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.