Every test passed and nobody could move
Players could join a raid and then not move. Not lag, not stutter. Frozen, and permanently.
The cause was two missing lines, and the reason nothing caught it is more interesting than the fix.
How prediction works, briefly
The client predicts your movement locally so the game feels instant. The server independently simulates the same thing and is the authority. When a snapshot arrives, the client rewinds to the server's state and replays its recent inputs on top. That is reconciliation.
That rewind copies a specific set of fields. Crouch had added a height field and lean had added a lean field. Both were hashed, both replicated, both predicted, and neither was in the list of fields the rewind restores.
Why that is fatal rather than cosmetic
Both are values the server can refuse. Standing up requires headroom. A lean is clamped if your eye would end up inside a wall.
So the client kept its own value forever. Its state hash never matched the server's, which meant every single snapshot arrived looking like a correction, which meant the client spent its entire existence being rewound. The player joined and could not move.
If the server had always agreed, the missing lines would have been harmless. The bug only exists because the server is genuinely authoritative: the feature and the failure come from the same place.
Why no test caught it
Every convergence test passed. Every one of them. They pass because none of them presses a crouch or lean key.
The tests drive forward, strafe, turn, and shoot. Under those inputs the two unrestored fields are always zero, always agree, and the hash matches perfectly. The tests were correct, thorough, and blind in exactly the shape of the new feature.
Two tests now cover it. One asserts the snapshot's values win. The stronger one runs a server through 120 ticks of crouching and leaning, restores a fresh client from the result, and asserts the hashes agree. Both fail if you remove the two lines.
The same shape, twice more
This class of bug, the tests only drive the case that already worked, had already happened twice in this codebase.
Lean was inverted. The code computed the player's right-hand direction with a sign error. Five tests passed throughout, because they asserted whatever the code produced rather than an independently derived answer.
The genuinely uncomfortable part: the movement code carries a comment saying this exact sign had been wrong there once before, and was "undetected because every movement test drives forward, and forward was correct." The note was written down, and the same mistake was made again anyway.
The fix was to re-derive the tests rather than adjust them, and to add one that compares leaning right against strafing right, the direction the game already gets right and the player can feel. That test cannot pass by encoding a convention, because inverting the offset makes it fail while naming both vectors.
And the weapon did not lean. The weapon is a child of the camera, so it followed the sideways movement perfectly and stayed bolt upright. The lean read as the world sliding rather than the player tipping. The camera now rolls ten degrees, so every child inherits it. Presentation only, so the shot, the visibility gate, the audio listener and the hitbox are all untouched.
The roll sign was wrong on the first attempt, and this time a test caught it.
Where the note went
There are five places a new predicted field has to be registered, and missing this one means the player joins and cannot move. That list is now a comment at the site itself, rather than something to remember.