Flaky test: WebSocket ping interval test fails intermittently on macOS-latest

[coderabbitai]

Description

A flaky test was detected in the CI pipeline for PR #207.

Test Details

Test Name: WebSocket Tests Given a web socket connection with a ping interval, when the client side blocks, then the server socket closes

Location: test/web_socket/web_socket_test.dart:354

Platform: macOS-latest (Dart stable, upgrade)

Failure Details

The test failed on the first run attempt but passed on retry.

Expected behavior:

• emit an event that <Instance of 'TextDataReceived'>
• emit an event that CloseReceived:<CloseReceived(1001, )>
• be done

Actual behavior:

emitted • CloseReceived(1001, )
x Stream closed.
which didn't emit an event that <Instance of 'TextDataReceived'>

Error:

TimeoutException after 0:00:30.000000: Test timed out after 30 seconds.

Links

• PR: fix: Build platform correct path when serving files. #207
• Failed workflow run: https://github.com/serverpod/relic/actions/runs/18400513696
• Failed job: https://github.com/serverpod/relic/actions/runs/18400513696/job/52428473683

Observations

This appears to be a race condition or timing issue specific to macOS runners. The test expects to receive a TextDataReceived event before the CloseReceived event, but on macOS the close event is sometimes received first.

The test succeeded on retry, confirming its flaky nature.

Suggested Actions

• Investigate the timing assumptions in the websocket ping interval test
• Consider adding more lenient timing expectations for macOS platform
• Review if the test's expectations about event ordering are too strict

---

Reported by: @SandPod in #207

[nielsenko]

Another run failed: https://github.com/serverpod/relic/actions/runs/18560415515/job/52907771944?pr=212
Bumping priority to 3

[nielsenko]

Another: https://github.com/serverpod/relic/actions/runs/18872674981/job/53854716885?pr=239
Bumping priority to 2

[nielsenko]

Yet again: https://github.com/serverpod/relic/actions/runs/18899504991/job/53943609813?pr=251
Bumping priority to 1

[nielsenko]

again: https://github.com/serverpod/relic/actions/runs/18937352327/attempts/1?pr=256
Bumping priority to 0. I guess this makes this issue the most important we have. Either that or we should re-evaluate the approach about bumping priority whenever we see a flaky test failure.