Document real Forge client Uranium login stall

smoke/results/2026-09-26-uranium-login-stalls.md

@@ -23,3 +23,15 @@ A second fresh Uranium process received 100 direct logins with TCP_NODELAY and b
 The smoke's optional `-TraceBackend` runs a local byte-forwarding relay in front of each copied Uranium server. It records the first 512 bytes per direction after a successful socket write. In `build/local-uranium-transfer-d13bae0327fe46b8b87b4e7257905aeb`, the initial login through the `old` relay succeeded. The proxy then connected to the `new` relay, and that relay connected to Uranium and forwarded a 29-byte Handshake plus Login Start (`0f0005096c6f63616c686f7374f595020c000a4e6574747950726f6265`). No bytes returned from `new`; its early login log remained empty; the candidate timed out after 15 seconds while its proxy channel was still active. This rules out a missing proxy write as the explanation for that failure. A successful control run, `build/local-uranium-transfer-64ee3ab68c2040d497590813d65831ab`, forwarded the same protocol payload with a different handshake port and received Login Success and Forge traffic from `new` within about 0.2 seconds; the full roundtrip passed.
 
 The relay confirms a successful write to a TCP socket connected to Uranium. It still cannot prove that Uranium decoded or queued the bytes, nor that its connection manager was removed before activation. The server-side lifecycle remains the discriminating evidence needed for the source-based race hypothesis.
+
+## Real Forge client reproduction
+
+The same class of stall occurred with the Prism Launcher Minecraft 1.7.10 / Forge 10.13.4.1614 client in `build/local-uranium-transfer-29e6b7c0fb204d54a61edf847ca18fc0`. The client launched, connected through StrataProxy, and logged into `old` as `PrismSmoke` at 04:08:44. The installed proxy plugin then requested a transfer to `new`. StrataProxy logged the candidate TCP connection and successful login-frame flush at 04:08:44.687. After 15 seconds it reported `backend login timed out`; the candidate channel was still registered and active. `new` had been ready since 04:08:23 and had `logging.user-login: true`, but its `latest.log` contained no `Login attempt`, disconnect, or player entry. The client's `latest.log` confirmed its initial connection to the proxy; it did not report a transfer completion. The smoke stopped the client after the failed transfer. The local Uranium bundle JAR SHA-256 was `B16747D08BAD4B7C67DB8F1F41C9C31066FEAAAC22B527775F604BDFA885BAD2`; its source checkout was `d7a68f934f` with pre-existing unrelated changes.
+
+This demonstrates that the issue is not limited to the synthetic protocol probe. It does not prove that Uranium is the sole cause; the direct Uranium login checks above did not reproduce it, and the exact server-side lifecycle of the failed connection was not recorded.
+
+## Uranium source audit
+
+In the inspected Uranium source, `CauldronConfig.userLogin` defaults to false. `NetHandlerLoginServer.processLoginStart` logs `Login attempt` only when that option is true; the usual `logged in with entity id` line comes much later in `ServerConfigurationManager.initializeConnectionToPlayer`. Therefore the latter line cannot be used to decide whether Uranium received the initial login packet. In the failing runs, the option was explicitly true on the target server, so the absence of `Login attempt` means `processLoginStart` was not reached.
+
+The possible early-removal interleaving remains a hypothesis: `NetworkSystem.addLanEndpoint` adds the manager before `NetworkManager.channelActive` assigns its channel; `networkTick` removes managers whose `isChannelOpen()` is false; the Handshake packet has priority and can run on Netty I/O, while Login Start uses the main-thread queue. `NetHandlerHandshakeTCP.onDisconnect` is empty, which also explains why an early handshake-stage close can lack a player-specific line. A Uranium-side connection lifecycle trace is needed to confirm or reject this hypothesis. No Uranium source change was made for this investigation.