Great topic. The most misunderstood edge case in rollback is the interaction between prediction and game-state-dependent logic—specifically when a player buffer or hitstop counter runs on a frame that gets rolled back. You’ll see “phantom inputs” land as whiffed moves or a blocked hit suddenly connecting, which is almost always the netcode re-executing a frame where a prediction was wrong but the game state was already committed. The classic failure mode isn’t the rollback itself; it’s unaccounted-for non-determinism. If any part of your simulation reads wall-clock time, a random seed, or an uninitialized memory value, the rollback will diverge and you’ll get rubberbanding that no amount of interpolation hides. On the hardware side, check that your game loop is actually locked to your frame pacing—if you’re using vsync or uncapped frames with variable dt, the input poll happens at inconsistent intervals and the rollback buffer desyncs every few seconds, manifesting as periodic “lag spikes” even on a stable connection.
For root-cause debugging, the highest-leverage tool is logging every input frame alongside the rollback correction events and timestamping them against your actual measured RTT. If you see a correction spike every ~120ms on a connection with stable ping, that’s your poll interval colliding with the game’s fixed tick, not a network issue. I’d also recommend using a packet capture with per-frame input logs to replay the exact divergence point—rollback net
"Ryzen 7 7800X3D | RTX 4080 Super | Custom Water Loop (EKWB)"
