TestHandleTeammateMessageSchedulesStreamedRun fails CI intermittently under
-race. Two separate races, both in the test rather than in what it exercises:
1. It shared `gotReq` between the scheduler's RunFunc and the assertions. The
RunFunc runs on a scheduler goroutine, and the announce loop schedules a
second run after the teammate one, so the write could land while the test
was reading — and the second run also closed an already-closed channel.
Requests now arrive over a buffered channel: no shared state, and a second
run cannot clobber the first.
2. The deferred sched.Stop() ran while handleTeammateMessage's background
goroutine was still calling Schedule, so Lane.Submit's wg.Add raced
Lane.Stop's wg.Wait. The gateway drains BgWg before stopping the scheduler
(gateway_consumer.go waits on it; sched.Stop is an outer defer in
gateway.go); the test skipped that step. It now drains too, which also makes
the test match the shutdown order it is meant to represent.
Reproduced before the fix with `-race -count=60 -cpu=1,4` (fails within a few
iterations) and clean afterwards over `-count=200 -cpu=1,2,4`, plus the whole
cmd package under -race.
Nothing in production changes; `Stream: true` and the channel-manager assertion
are untouched.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Review on #1533 asked for coverage of the behavioural contract rather than
the field assignment, and that is the right call — the PR text arguing a test
would only restate the assignment was wrong, because the contract has two
halves that a refactor could break independently.
The test drives handleTeammateMessage through a real scheduler and asserts
both: the scheduled run requests streaming, and the run is not registered with
the channel manager, so its chunks cannot be routed to a user. It fails with
Stream reverted to false.
The remaining half — a streamed call still yielding the complete final response
— is already covered in internal/agent/loop_pipeline_callbacks_test.go.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
