From 4450359428b4e0760f2c652767376a773bba0e46 Mon Sep 17 00:00:00 2001 From: Brandur Date: Thu, 16 Jul 2026 18:10:15 -0500 Subject: [PATCH] Fix intermittent test `TestProducer_PollOnly/JobStuckHandlerOpensExecutorSlot` Fix an intermittent test noticed in CI on another PR [1]. Just changes the test to only add a worker slot on the first stuck job which makes the test a little more reliable in slower test environments. Previously the test opened a replacement slot for every stuck job. After job 1 became stuck, job 2 started in the replacement slot. Because job 2 also blocked and used the same short timeout, depending on timing, it could also be marked stuck before the assertion ran, causing another replacement slot to be opened, and reducing counted active jobs to zero, with the assertion assuming only job 1 had been handled. The fix here is to make sure that only one replacement slot can be opened. [1] https://github.com/riverqueue/river/actions/runs/29541028860/job/87763137367?pr=1312 --- producer_test.go | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/producer_test.go b/producer_test.go index 69a2f8bf..58f6fb90 100644 --- a/producer_test.go +++ b/producer_test.go @@ -574,7 +574,11 @@ func testProducer(t *testing.T, makeProducer func(ctx context.Context, t *testin handlerParamsCh := make(chan JobStuckHandlerParams, 2) producer.config.JobStuckHandler = func(ctx context.Context, params JobStuckHandlerParams) JobStuckHandlerResult { handlerParamsCh <- params - return JobStuckHandlerResult{AddWorkerSlot: true} + + // Only replace the first stuck job. The second job may also pass the + // short test timeout before the assertion runs on a busy machine, but + // it should continue occupying its executor slot in that case. + return JobStuckHandlerResult{AddWorkerSlot: params.TotalStuckJobs == 1} } var (