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

A heavy package run outside make takes no suite lock

Ouverte
#1,320 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

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

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
55/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
bash, go

Piste de recherche

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.

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

Description

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.

Langage dominant
Go
Étoiles
115
Forks
14
Merge moyen
9 h 37 min
PR mergées (30 j)
755

Préparer son environnement

Nous n'avons pas encore vérifié les fichiers d'installation de ce projet. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

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

Toutes les issues de Agent-Field/CodeAF

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.