The most common root cause of rubberbanding isn’t prediction itself—it’s reconciliation handling on out-of-order and dropped packets. When you buffer inputs and send them to the server, you need to track every input’s sequence number and timestamp, because the server’s authoritative simulation will replay them in order but your client may receive them scrambled. A classic failure mode is when a packet loss causes your reconciliation queue to replay a later input while skipping the one that was dropped—your client snaps back because the server effectively “fast-forwarded” past a state you’re still simulating. The fix is to always send the full current input queue (or at least a contiguous window from the last acknowledged input) on every message, and to detect gaps by comparing the latest received sequence number against your sent queue. If you only send the newest input, you lose the ability to reconstruct the missing step.
For debugging, stop eyeballing the visual snap and instead log three parallel timelines: client prediction state, server-acknowledged state, and the raw input stream with sequence numbers and RTT timestamps. The moment these diverge is where you isolate the bug. A good heuristic: if the desync only appears after ~200ms and then corrects itself, it’s almost always a reconciliation replay-order issue rather than a prediction bug. Prediction errors manifest immediately and locally, right when you press a button, while reconciliation errors lag by one round-trip. Also, don’t underestimate interpolation of remote entities masking real problems—if your render lag is too high, you’ll hide prediction errors behind smooth movement and never find them. Try setting interpolation buffer to zero during debugging to expose the true desync, then reintroduce it once
