Two things needed to happen for the reported error:
-
There needs to be no state in storage when an load event happens. By documentation, the load event only happens when the mod was in the save before. I changed storage format in v1.0.0. So loading of an older mod state would actually lead to this scenario.
My load event handler didn't check for nil before copying the state from storage to a local variable for efficiency (I fixed that).
The tick event handler does check for nil of the local state and just reinitializes it to self-heal though. That is probably why I didn't get reports from people continuing old saves from Factorio 1 on Factorio 2 (v1.0.0 is the first compatible version).
-
The object_destroyed event handler didn't check the local state for nil (I fixed that by removing the handler). So if after loading an old save an object_destroyed event happened before my mod's tick event handler in the first tick of the loaded game, the reported error is exactly what would happen.
This event is documented to always fire at the end of the tick. But it looks like it still can happen before the tick event regardless.
This is definitely an edge case highlighting the need for always doing at least a quick sanity check when dealing with storage.
If you loaded a save with a pre-v1.0.0 Inserter Fuel Leech the case is somewhat explainable. Maybe, the tick event doesn't happen in editor mode and object_destroyed events happen on destruction rather than at the end of the tick (which could be far off in the future when editing a map). Another mod could have somehow registered every entity on the map to trigger an object_destroyed event.
If you didn't load a save with a pre-v1.0.0 Inserter Fuel Leech, it's a case for the X files because in that case the local state is a dummy which is a full functioning state with an invalid version field. It couldn't be nil in the object_destroyed event handler because the only write of an unknown value was in the load event handler.