Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

A heavy package run outside make takes no suite lock

Aberta
  • Algo errado?
#1,320 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
55/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
bash, go
Domínio
build-system, testing-qa, tooling

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Go
Estrelas
115
Forks
14
Merge médio
11h 40min
PRs com merge (30d)
203

Preparar o ambiente

Ainda não verificamos os arquivos de configuração deste projeto. Comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de Agent-Field/CodeAF

Todas as issues de Agent-Field/CodeAF

Issues semelhantes

Mais issues de Go

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.