make the test loop less race'y

[Tofel]

Suspect

Race between Go async preemption and the test's default branch. The select could pick default (reads buffer empty), and before p.CurrentPartitionIdx() was called — a function-call safe point — the goroutine could be preempted. During that suspension, scheduleReadJobs fired all 3 ticks (30ms), incrementing currentPartitionIdx to 3 and sending items to reads. On resume, the test loaded partitionIdx = 3, broke immediately, and never ran another select — leaving items in reads unconsumed and got empty.

Fix

Replaced the racy busy-wait default case with a blocking loop that exits only when all expected IDs appear in reads.

[github-actions]

✅ No conflicts with other open PRs targeting develop

[cl-sonarqube-production]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube

[trunk-io]

     

View Full Report ↗︎ ⋅ Docs

[Copilot]

Pull request overview

Risk Rating: LOW

This PR updates a concurrency-sensitive test loop in TestLogEventProvider_ScheduleReadJobs to avoid a race between a non-blocking select { default: ... } branch and async goroutine preemption, which could previously cause the test to exit early and leave scheduled reads unconsumed.

Changes:

• Replaced the busy-wait select loop (with default + runtime.Gosched()) with a blocking loop that continues until all expected IDs have been observed.
• Removed the now-unneeded runtime import from the test file.

Areas requiring scrupulous human review:

• None beyond confirming this test’s new termination condition matches the intended assertion semantics (it now exits only once all expected IDs are seen, or fails via timeout/context).