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

A heavy package run outside make takes no suite lock

Abierto
  • ¿Algo no está bien?
#1,320 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
55/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
bash, go
Área
build-system, testing-qa, tooling

Línea de trabajo

Start with Makefile:125-126, scripts/one-suite.sh, and cmd/codeaf-suite-lock to trace how heavy packages enter the locking scheme. Compare the Makefile test path with a direct go test ./internal/session run, then define how an unattended contender waits with a timeout and records wait time. Done means heavy runs cannot proceed unlocked and contention is not reported as a work failure.

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

Descripción

area:tests bug sev:serious

The one-suite rule binds make, not the box. scripts/one-suite.sh opens with
the reason the lock exists: nine sessions fired go test ./... at once, the
reds that came out were manufactured by the load, and so "a second run on the
same box refuses to start and says who holds it rather than joining the pile."

A second run started as go test ./internal/session does not refuse. It does
not see the lock, does not take one, and nothing tells it to. It is the same
workload the lock exists to serialise, entered by a door that has no lock on it.

Observed on the box, 2026-09-20T19:25Z

Two heavy runs alive at the same instant, one holding the lock and one not.

The holder, correct in every respect:

  • pid 1555853, bin/codeaf-suite-lock --hold-heavy-suite-lock 1555852 302442410,
    cwd /home/santosh/src/trees/sdev-e098ca1fd, holding fd 3 on
    /tmp/codeaf-suite-1001.lockfile.
  • Its parent chain is bash /tmp/gate.sh e098ca1fd then make check then
    codeaf-suite-lock /tmp/codeaf-suite-1001.lockfile go test -count=1 -timeout 15m.
    It went through the Makefile, so it took the lock.

Beside it, taking nothing:

  • pid 1531326, go test ./internal/session, started 19:21:29Z, 4m20s elapsed at
    the time of reading, a direct child of an ordinary shell.
  • It started about forty seconds BEFORE the gate took the lock, so the gate did
    not refuse either: there was nothing to refuse against.

Box load reached 14.52 with both up.

This is not #1307

#1307 is two lock mechanisms that cannot see each other, both of which are
trying to participate. This is a runner that never enters the scheme at all. It
is not failing to cooperate, it has no cooperation to fail at.

The distinction decides what a fix is worth. Every remedy in #1307, dual
checking on the read side and taking both locks in one-suite.sh, could land
tomorrow and this hole would be exactly as open as it is now. A reader of #1307
alone would reasonably conclude the flock closed it.

Put plainly: the lock does not protect the box from every heavy run, only from
the ones that went through make. A lock that binds only the compliant is a
convention with a syscall in it.

The mechanism, from the repo's own files

Makefile:125-126

HEAVY_PKGS := ./... ./internal/tui3 ./internal/tui3/ ./internal/session ./internal/session/
SUITE_LOCK := $(if $(filter $(HEAVY_PKGS),$(PKGS)),./scripts/one-suite.sh)

The lock is selected by the PKGS variable of the test target. scripts/one-suite.sh
says the same thing in prose: "The Makefile invokes this wrapper for a full
make test or test-report when PKGS contains ./..., ./internal/tui3 or
./internal/session."

So the binding is between the MAKE TARGET and the lock. It is not between the
PACKAGE and the lock, and the package is what actually loads the box.

Note that the Makefile already takes the neighbouring risk seriously one level
up. test-focus requires RUN and refuses without it, with the comment "an
omitted selector must not silently turn a focused command into a full package
run." That guards a focused run degrading into a heavy one inside make. It
cannot guard a heavy run that never enters make.

Refusing is the wrong answer for an unattended runner

cmd/codeaf-suite-lock refuses a contender and prints "Wait for it, or run one
named regression with make test-focus." For a person at a terminal that is
right: they read it and retry.

For an unattended runner it converts a scheduling fact into a false negative
about the work. A run that fails because the box was busy is indistinguishable,
in whatever report it writes, from a run that failed because the code is wrong.
That is the shape this repository keeps finding in other places: a single signal
that means two different things.

So whatever closes this should make an unattended contender WAIT, with its own
timeout, and record how long it waited in its report. Never proceed unlocked,
and never fail for contention.

What I am not claiming

I have not shown that the overlap above corrupted any result. Both runs may
finish clean. The claim is only that the box permitted two heavy suites at once
while one of them believed it held exclusivity, which is the state the lock was
written to make impossible.

Related: #1307.

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.