Skip to content

test: retry the vanilla ping while the server has no status yet - #1524

Open
u9g wants to merge 1 commit into
PrismarineJS:masterfrom
u9g:fix/ping-test-startup-race
Open

test: retry the vanilla ping while the server has no status yet#1524
u9g wants to merge 1 commit into
PrismarineJS:masterfrom
u9g:fix/ping-test-startup-race

Conversation

@u9g

@u9g u9g commented Sep 7, 2026

Copy link
Copy Markdown
Member

Problem

The client <version>v > offline > pings the server test fails intermittently on CI with:

Error: Connection closed before the server sent a status response
    at Client.<anonymous> (src/ping.js:47:14)

It hit three unrelated 26.1 runs in the last three days (the mocha 12 dependabot bump, #1521, and #1523). Before #1514 this case hung until the 120 s closeTimeout instead of failing fast, which is why it used to show up as a slow test rather than a red job.

Cause

It's a startup race in vanilla that the test harness's readiness check exposes:

  • minecraft-wrap resolves startServer as soon as the server logs the Done (...)! line, and the test pings immediately.
  • Vanilla logs that line inside DedicatedServer.initServer(), but only builds its ServerStatus afterwards in MinecraftServer.runServer() (after also stat'ing the favicon).
  • Since 1.19.4, ServerHandshakePacketListenerImpl.handleIntention runs on the Netty thread and, for a STATUS intent while getStatus() is still null, calls connection.disconnect(IGNORE_STATUS_REASON). In the status state that is a bare socket close with no packet.

In the failing logs the ping lands within the same millisecond as started server; in passing runs there is ~90 ms of slack.

Fix

Only the ping test is affected (the login path does not check the status object), so the test now retries that specific error for a bounded number of attempts with a short delay, instead of pinging exactly once. Any other error, or exhausting the attempts, still fails the test. src/ping.js is unchanged.

Verified locally: the 26.1 test passes under Java 25, and against a fake server that closes the first three status requests after the handshake the helper recovers, while against one that always closes it gives up with the original error after the configured attempts.

minecraft-wrap resolves startServer on the "Done" log line, which vanilla
prints inside initServer() before runServer() builds its ServerStatus.
Since 1.19.4 the handshake listener runs on the Netty thread and closes a
STATUS request that arrives while getStatus() is still null, so the
"pings the server" test intermittently failed with "Connection closed
before the server sent a status response" (three unrelated 26.1 runs in
the last three days). Retry that specific error for a bounded number of
attempts instead of pinging exactly once.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant