Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

A heavy package run outside make takes no suite lock

Đang mở
  • Có gì không ổn?
#1,320 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
55/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
bash, go
Lĩnh vực
build-system, testing-qa, tooling

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Go
Star
115
Fork
14
Merge trung bình
9 giờ 37 phút
Pull request đã merge (30 ngày)
755

Chuẩn bị môi trường

Chúng tôi chưa kiểm tra các tệp thiết lập môi trường của dự án này. Hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của Agent-Field/CodeAF

Tất cả issue của Agent-Field/CodeAF

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.