Question Simulation Control and Replays in Unity DOTS and Netcode

Not really. Depend what you record and actually more about how do you run your deterministic simulation.

To have a deterministic simulation there are various approach, but indeed having it running at fixed time step is definitively the more straightforward and probably robust.

So, given the situation runs at fixed step, and given the initial state is identical, all random identical, all source of randomness removed (so don't depend on time, or anything like that) re-running with just input will give the same result.
Even if the accumulated time may vary (because the delta time may vary) you are just resimulate everything at the same fixed frequency.
Accelerating or Decreasing the delta time is also fine. You accumulate less and so simulate less often. As well as, you accumulate more, and simulate more ticks per frame if necessary.

The problem is eventually how to handle the "partial" simulation steps. You can either interpolated the frame results (so you are running speculatively the next frame) or you playback slightly behind, or similar techniques.

If you want to rewind (go backward), you can store the last lets say second of simulation state (worst scenario is a copy of the world state, can be fast, @tertle has a solution that was backing up millions of entities realtime) or having already in the recording (suggested anyway) snapshot at regular or irregular intervals, and restart from there upward.

Having full state intermixed is also used to jump forward. You restore the state from X and move forward to the point you need.
Problem to solve are then usually effects, particles, audio. These stuff must be designed as much as stateless as possible (they only depend upon the absolute time) so they can rewind appropriately.

There is nothing special about ECS that makes it different in respect of any other solutions, apart the speed at which you may copy data, that open to some options that are less viable otherwise.

 

Attention: this may be not deterministic at all. Dunno how you are doing the simulation on both server and client and what the server replicate (maybe nothing, just forward input) but clients are not guaranteed to run the same ticks exactly as the server: partial ticks and catch up (some ticks may skipped). may mess up. You are guaranteed to run the same ticks though in the prediction loop. However, client may be doing that multiple time if it receive predicted ghost data.
Not even talking about the fact , the client may update or resimulate only some ghosts (partial snapshots). And that would already cause a divergence in the simulation time 0.
Even admitting it does not, because the ghost are not interacting/influencing each other, that would still introduce the fact the seed (that looks like is common or shared among entities) may be called a different number of time on Server and Client.

Again, without known detail is hard to give advice, but a safer solution is that every ghosts should have its own seed, and it should still need to be rollback as necessary. (it may be even replicated, if not for sake of checking what you have locally is consistent). This at least in a generic setting scenario.

Yes, there is a cost with checkpoint. But depending on the type and replay need it may be a cost that you may be willing to pay to jump at any point of the replay in "realtime".

I agree, this is one is big advantages. ECS though is technically stateless by itself. It is stateless if you make and programming like that. So it is always a matter of how you write your systems (rule of thumb: no caches, no state, every data it touch must be in the entity storage). And similar results can be achieved without a pure ECS implementation (