Authoritative server sends state of multiple, but not all, entities periodically.

Client receives and re-simulates all entities from server's state, or locally saved states if entity is not included in update.

Now imagine short-lived entities on the client.

An entity is created at time 1 and destroyed at time 3.

At time 4 an update arrives, with info on time 2, and the client rolls back to time 2, in order to re-simulate from time 2 to 4.

The update did not include the already destroyed entity, but may include entities affected by it.

There are no locally saved states for the destroyed entity anymore, because it's destroyed.

The re-simulation would diverge because the destroyed entity is gone and will not be able to affect other entities in re-simulation.

I am thinking of some kind of zombie-mode for entities, which wouldn't be easy to integrate to the used ECS, to keep them around for eventual revive for rollbacks/resims.

Or keeping entity-states outside of entities, and recreate destroyed entities when rolling back past the time of their destruction.

Or not allowing rollback past destruction, which isn't a real solution.

It seems to me i cannot completely avoid this problem, and all solutions i can think of are kind of cumbersome.

What to do in such a case? Surely there has to be some obvious, easy and performant solution i just did not think of ... 

The easiest way is to make your client side simulation handle entities completely independently, rather than having the potential for a server update from one to interfere with a client update for the other.

Another way to make your life easier is to avoid all this 'rollback' stuff unless you're 100% sure you need it. In most games, you don't.

Thanks for you input.

Hm... no rollback-stuff... that would be nice, because that is ... rather complicated - and grows evermore so. The physics aren't deterministic and updates arriving are ofc from the past. Hm. I remember trying to not resimulate but just calculate corrections against past position/vel/accel and applying delta in the present. It looked off unless i used a high rate of updates and went with just a little latency. But a little prediction/extrapolation of these delta might improve that... However applying other state like logic, health or other scripted state might get messy without proper resimulation.

Will have to think about that some more.

By your first point - do you mean entities from each other, or received states from local states? Sounds like both kind of. 

But because of the physics-sim with interacting forces i cannot see either atm. 

Currently the rollback-stuff EATS cpu - a high rate of updates and a very high latency means simulating each frame like 10 times over. Thats not ideal. Using lower rates of updates kind of makes it ok, and there is almost 0 difference between server and client with the resimulations - which is rather cool. except ofc for the issue above...

About needing rollbacks - 2d, multiple players with gamepad-style inputs that have immediate effects, physics where world/pve-collision is more important than pvp-collision - targeting inet latency. The player is supposed to have a jump'n'run-y experience, with prompt response of his avatar and the world, where other players' actions need be visible but not necessarily fully in sync. 
So i *think* i need it - but your comment shall make me think about that need again.

Most engines make "object create" and "object delete" messages high priority, pushing them out ASAP. You'll also want to make sure that they get re-sent until they're acknowledged by the other side, to avoid object lifetime de-sync (which is worse than object state de-sync.)

Ah yes... i put off implementing "object delete" messages thinking "ah, just let them timeout" or something.
which was stupid.
those were rather easy to implement, they get spammed until ACK, then all ACKed entities are removed from the set. 
these partly solve my problem already. once one of those arrives, i can be sure there will be no more updates that might in any way depend on the removed entity. (except for some heavy out-of-order arrival, but can't have it all)
that leaves a window of ping/2 in which a problematic update might arrive.
for now i put entities in a zombie-state on the client and truly destroy them once the "object delete" arrives.
in zombie-state i can revive entities for rollbacks, during which they will ofc get killed again.
poor entities.

i have brainfood for now to go on and solve my initial issue.
still thinking about the rollback-system as a whole, re-reading gaffer's and the valve-docs for the Nth time - but i guess that's another thread. 

thanks Kylotan and hplus0603 for your input.