Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

internal/session: TestWorkNoWorkerCanDoStopsARunningWorkerAndLandsOnThePerson races a 30 s wall and fails beside another suite

Offen
#1,339 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
78/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
go
Bereich
testing-qa

Rechercherichtung

Start with TestWorkNoWorkerCanDoStopsARunningWorkerAndLandsOnThePerson and the eight time.After(30 * time.Second) sites in internal/session/task_divide_sketch_test.go. Run the focused session test beside the internal/tui3 suite with GOMAXPROCS=4 to reproduce the race, then inspect the held completer and worker-stop acknowledgement. Done means no fixed 30-second waits remain, waits respect owned synchronization or the test deadline, and the concurrent -count=5 run passes.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

area:session area:tests bug sev:papercut

What happened

2026-09-21, dev@17ae56d34 plus the seven-plus-six commits of #1336 (which touch nothing in the task harness), running the repository's own gate on a laptop while a second full suite and a read-only reviewer were also running:

make pr-ready
…
--- FAIL: TestWorkNoWorkerCanDoStopsARunningWorkerAndLandsOnThePerson (37.55s)
    task_divide_sketch_test.go:594: the worker was never stopped for work only a person can do
FAIL
FAIL	github.com/Agent-Field/codeaf/internal/session	799.740s

The package took 800 s against the 210 s constrained-runner baseline in CLAUDE.md. CI's touched packages job on the same head passed. The same test on a quiet box:

go test -count=3 -run '^TestWorkNoWorkerCanDoStopsARunningWorkerAndLandsOnThePerson$' ./internal/session/
ok  	github.com/Agent-Field/codeaf/internal/session	0.879s

So it is the shape CLAUDE.md says is a bug report and not a known one: a session test that fails only when other suites run beside it.

Replication

Deterministic (no model). Run the session suite while another heavy suite runs beside it, on a box with a few cores:

GOMAXPROCS=4 go test -count=1 -timeout 15m ./internal/tui3/ &
GOMAXPROCS=4 go test -count=1 -timeout 15m -run 'TestWork' ./internal/session/

What a developer sees today, some of the time: the --- FAIL above after 30 s of waiting. On a quiet box it passes in well under a second.

Field (real models). Not applicable: this is a test's own wall, no product door.

Where

TestWorkNoWorkerCanDoStopsARunningWorkerAndLandsOnThePerson in internal/session/task_divide_sketch_test.go, and its siblings in the same file: each waits on a channel with case <-time.After(30 * time.Second) (search that string; eight sites). The worker being stopped is real work driven by a held completer (completer.hold); on a loaded box the stop lands after the thirty seconds have gone.

The fix

A test in this package should not lose a race against wall time. Either the wait is on a sync point the harness owns (the held completer's release, the worker's own stop acknowledgement) with no timer at all, or the ceiling is the test's deadline (t.Deadline() minus a margin) rather than a fixed thirty seconds. CLAUDE.md's learned preference already says it: deterministic clocks over real sleeps.

Acceptance

  • e2e: not applicable — nothing crosses a product door; the defect is the test's own timer.
  • Unit: every wait in task_divide_sketch_test.go is either a sync point with no timer or bounded by the test deadline; grep -c 'time.After(30' internal/session/task_divide_sketch_test.go is 0.
  • Unit: the test passes with -count=5 while go test ./internal/tui3/ runs beside it on a 4-core box.
  • No manual page or change entry is involved.
Vorherrschende Sprache
Go
Sterne
115
Forks
14
Ø Merge
15 Std. 42 Min.
Gemergte PRs (30 T.)
235

Entwicklungsumgebung

Die Einrichtungsdateien dieses Projekts haben wir noch nicht geprüft. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus Agent-Field/CodeAF

Alle Issues in Agent-Field/CodeAF

Ähnliche Issues

Weitere Issues zu Go

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.