Flaky test: BindOperationTestCase.testSubtreeModifyUpdatesAuthInfo — Connection refused right after in-process server restart

[vharseko]

Summary

BindOperationTestCase.testSubtreeModifyUpdatesAuthInfo failed once on build-maven (ubuntu-latest, 17) with java.net.ConnectException: Connection refused on the very first RemoteConnection opened right after TestCaseUtils.restartServer(). All other 8 matrix jobs of the same run passed, and the failure is unrelated to the PR being tested (#754, BouncyCastle FIPS bump — the BC FIPS provider installed fine and the server started normally).

Failed run: https://github.com/OpenIdentityPlatform/OpenDJ/actions/runs/29724957232/job/88295808274

[ERROR] org.opends.server.core.BindOperationTestCase.testSubtreeModifyUpdatesAuthInfo -- Time elapsed: 5.325 s <<< FAILURE!
java.net.ConnectException: Connection refused
    at org.opends.server.tools.RemoteConnection.<init>(RemoteConnection.java:91)
    at org.opends.server.tools.RemoteConnection.<init>(RemoteConnection.java:84)
    at org.opends.server.core.BindOperationTestCase.testSubtreeModifyUpdatesAuthInfo(BindOperationTestCase.java:1582)

Analysis

Timeline reconstructed from the test's server error log (logs/errors):

• 08:48:56 — the test starts and calls TestCaseUtils.restartServer(); the in-process restart takes ~5 s on the slow runner (08:48:56 → 08:49:01);
• 08:49:01 — Started listening for new connections on LDAP Connection Handler 0.0.0.0 port 65535;
• 08:49:01.4 — the test fails to connect to that port.

The connect and the listener bind land in the same second — a race between the restarted server and the first client connection. The wait-for-listen handshake in LDAPConnectionHandler.start() is not bulletproof: it uses a bare waitListen.wait() with no condition loop (an early return on a spurious wakeup/interrupt is possible), and the !enabled branch in run() notifies the waiter before any channel is bound. RemoteConnection connects exactly once, with no retry.

Notably, this same pair of tests was already de-flaked once in 3cc8bed (#727), but that fix addressed the POST_RESPONSE AuthenticatedUsers polling race, not the connect-after-restart race.

Proposed fix

Either (or both):

• wrap the initial RemoteConnection creation in the existing TestTimer.repeatUntilSuccess(...) helper (same approach as Fix flaky BindOperationTestCase subtree auth-info tests #727) in both testSubtreeModifyUpdatesAuthInfo and testSubtreeDeleteClearsAuthInfo (same construct at BindOperationTestCase.java:1513);
• make TestCaseUtils.restartServer() poll the LDAP port until it actually accepts connections before returning.