# resim-mismatch

> Talos next · Since next

the re-simulate-twice check (`POST /desync { "resim": true, "depth"?: N }`) ran a tick a second time from an earlier snapshot (the same tick's, or with `depth` N the snapshot of a tick up to `2 * (N - 1)` back, run again with the inputs it had) and the second run's state differs from the first's: something outside the snapshot steers the tick (a module-level variable a behaviour writes, one that holds a value from a later tick, a cache, a system whose restore is not exact); said once, with the tick, the system, the entity and the first fields that differ with both values (and the depth, when above 1), and kept as the last desync report (`GET /desync`, `mode` `resim`); after it the check stops and ticks run once

| | |
|---|---|
| Severity | `warning` |

## Meaning

the re-simulate-twice check (`POST /desync { "resim": true, "depth"?: N }`) ran a tick a second time from an earlier snapshot (the same tick's, or with `depth` N the snapshot of a tick up to `2 * (N - 1)` back, run again with the inputs it had) and the second run's state differs from the first's: something outside the snapshot steers the tick (a module-level variable a behaviour writes, one that holds a value from a later tick, a cache, a system whose restore is not exact); said once, with the tick, the system, the entity and the first fields that differ with both values (and the depth, when above 1), and kept as the last desync report (`GET /desync`, `mode` `resim`); after it the check stops and ticks run once

## Fix

find what the named system and field hold that a snapshot does not: for a script field, the behaviour keeps state in a module-level variable (`script-module-state` names it) and belongs in `ctx.state`; `GET /desync/dump?system=&entity=` shows the field's value now