Intermittent 403 in QueryErrorWireTest from something outside the application

[aaylward]

Every Micronaut test that boots an EmbeddedServer sets micronaut.server.port = -1, which makes Micronaut draw a random port with SocketUtils rather than taking an OS-assigned ephemeral one. From micronaut-core 5.1.10:

MIN_PORT_RANGE = 1025
MAX_PORT_RANGE = 65535   // picked with java.util.Random

That range covers ports other processes hold. On macOS, ControlCenter (AirPlay Receiver) listens on 5000 and 7000 and answers 403 to any HTTP request:

$ lsof -nP -iTCP -sTCP:LISTEN
ControlCe *:5000
ControlCe *:7000
$ curl -o /dev/null -w "%{http_code}" http://localhost:5000/v1/query
403

Seen once in a full bazel test //... --nocache_test_results run:

FAIL: //domains/games/apis/one_d4:...api/QueryErrorWireTest
  wellFormedQuery_returns200()
  org.opentest4j.AssertionFailedError: expected: 200 but was: 403

one_d4 has no 403 path in its sources, and the run's log carries no query_event for that request though every other method in the class logged one — the request never reached the application.

Not reproduced in 57 further executions, which matches a ~2-in-64k draw per server boot. 18 test classes use this setting, so the exposure is the whole embedded-server suite, not one test.

What is not established: Micronaut probes a port before binding, so a draw of 5000 should have been rejected. How getPort() came to report a port ControlCenter owns is untraced — the probe/bind window is the place to look.

Fix direction: bind an OS-assigned ephemeral port and read back the real bound port, instead of the random-range picker.

[aaylward]

The port mechanism in the description is wrong — retracting it.

I measured the ports these tests actually bind, by printing server.getPort() in @BeforeEach. 72 boots under micronaut.server.port = -1:

samples: 72  min: 53818  max: 53960  below_ephemeral(49152): 0

All inside the kernel ephemeral range, assigned sequentially. Setting "0" instead produces the same thing (53788-53798). So on this path -1 already binds an OS-assigned ephemeral port, and SocketUtils.findAvailableTcpPort — whose 1025-65535 range the description leans on — is not what picks it. 5000 and 7000 are never in play, and there is no fix to make here.

NettyHttpServer.getPort() also reads back channel.localAddress().getPort() from Netty once listeners are active, so the reported port is the real bound one, not the configured value. That closes the one gap the description flagged as untraced.

What still stands: the 403 on wellFormedQuery_returns200 happened, one_d4 has no 403 path of its own, and the run logged no query_event for that request though every other method in the class logged one — so the request did not reach the application. What answered it is unknown. ControlCenter does hold 5000 and 7000 and does answer 403, but nothing now connects the test to those ports.

Retitling to match what is actually known. Still open, still unexplained, and not reproduced in ~130 further executions.