How to deal with server_late_input_mismatch in 0.27?

[wlinna]

Hello,
ever since upgrading to 0.27, I have been getting consistent of ERROR lightyear_debug::input: server received initial input for an already-simulated tick kind="server_late_input_mismatch".
It happens exactly once for every controllable character after players move from lobby to the level and spawning the wizard.
Otherwise I don't seem to get this error.

Here are the relevant logs I get:

2026-06-24T14:46:14.262557Z DEBUG lightyear_inputs::server: Adding InputBuffer and ActionState which are missing on the entity       
DEBUG lightyear_inputs::input_message: Mismatch detected at tick Tick(723) for
    new_input = Some(LeafwingSnapshot(ActionState { /* all actions Release , value 0.0 */ }))
    Previous predicted input: None

  ERROR lightyear_debug::input: server received initial input for an already-simulated tick
    kind="server_late_input_mismatch" schedule="PreUpdate" sample_point="PreUpdate"
    entity=237v0 client_entity=232v0 client_id=Netcode(...)
    action="mygame_protocol::input::NetworkedInput"
    local_tick=725 mismatch_tick=723 end_tick=723
    previous_last_remote_tick=None last_remote_tick=Some(Tick(723)) buffer_len=1
    input_buffer:
      Tick(723): LeafwingSnapshot(ActionState { /* all actions Released, value 0.0 */ })

When the match starts, I add ActionState::<NetworkedInput>::default() to every wizard on spawn.

Can someone point out what this error even means? Why do I get Adding InputBuffer and ActionState which are missing on the entity when I'm clearly adding them?

Best regards

[false200]

@wlinna

The error means the server hit tick 725 before it ever got an input buffer for that wizard. The first packet says end_tick 723, but 723 and 724 already ran in FixedUpdate with nothing buffered, so 0.27 logs server_late_input_mismatch. That tick can't be replayed. Your input is all Released anyway so one log at spawn is usually harmless if movement works after.

The "Adding InputBuffer and ActionState which are missing" line isn't saying you didn't add ActionState. Lightyear checks for InputBuffer on receive. You only insert ActionState on spawn, so the first packet still hits the insert path and lightyear adds both itself. Examples like simple_box don't pre-insert either.

Once per wizard at lobby to level is a spawn race. Client has a Predicted wizard and starts sending inputs right away, server entity exists but the first packet lands a tick or two late.

To deal with it — if it's one log per character and then fine, ignore it. Otherwise on server spawn insert InputBuffer alongside ActionState:

commands.entity(wizard).insert((
    ActionState::<NetworkedInput>::default(),
    InputBuffer::<LeafwingSnapshot, NetworkedInput>::default(),
));

Also make sure inputs target the replicated server entity not a client-only copy, and don't start sending until the wizard is confirmed spawned. If it keeps happening every tick after that, chase timeline sync around the transition.

[cBournhonesque]

To add to that, I think what is happening is: (tick value here are for example)

• on client, user presses inputs on ticks [100, 101, 102, 103, 104] (current client_tick is 104)
• an input messages is sent to the server, when it's at tick 102. Server tires to create/update its input buffer with values from the buffer.
• It is very important that the inputs arrive on the server BEFORE the server simulates a tick, but here the server receives the inputs for some older ticks (100, 101) even though it had already simulated them with nothing buffered, so there is a mismatch.

Lightyear is warning you that a mismatch is possible here; if the client had pressed a button at tick 100 or 101, the server would just ignore those inputs since it received them too late.

Several options:

• in lightyear, ignore the mismatch if the inputs were 'Released' as basically there is no real mismatch (no input in the buffered vs 'released' inputs received from the client)
• the bug might come from the fact that i start to buffer all inputs instantly; even before the input timeline is Synced (https://github.com/cBournhonesque/lightyear/blob/main/crates/inputs/inputs/src/client.rs#L273) but I only send input messages after the timeline is synced (https://github.com/cBournhonesque/lightyear/blob/main/crates/inputs/inputs/src/client.rs#L1075)

I do this because the player might hit buttons before the input timeline is synced, and these would be ignored if i didn't buffer them. But they might get ignored on the server anyway so maybe there's no point?
i.e what could happen is:

• client start
• buffer becomes [Fire - Tick0, Fire - Tick1]
• InputTimeline gets synced => the buffer ticks get adjusted to [Fire - Tick100, Fire - Tick101]
• Next frame, we send an input message [Fire - Tick100, Fire - Tick101, Fire - Tick102], which the server receives when they are at tick 101. The server hasn't simulated Tick100 so there would be a discrepancy.

If I only buffered inputs after the input timeline gets synced, the input buffer would be empty for ticks 100, 101 and this problem disappears.
I think I will do this change, thanks for the report

[wlinna]

Thank you very much for your answers. I will ignore the error for now.

@false200 I tried inserting InputBuffer::<LeafwingSnapshot, NetworkedInput>::default() with the ActionState, but that is not enough.

[false200]

@wlinna Yeah, that makes sense. Setting InputBuffer on spawn helps on the server side, but I think @cBournhonesque found the actual root cause. The client starts buffering inputs before its input timeline is fully synced, which shifts the ticks and causes the first packet to arrive with tick values the server has already moved past. That's not really something you can fully work around in game code since it's happening lower down in the networking layer. For now, ignoring the warnings is probably fine, especially since all of your buffered inputs are Released anyway, so nothing meaningful is being lost. Once the client-side buffering fix lands upstream, I'd expect the spam to go away by itself.