thread 'main' panicked at 'Entity does not exist'

[ndarilek]

Bevy version

47004df)

Operating system & version

Windows 10

What you did

I have a system that adds/removes unit struct components via Commands. Sometimes my game runs fine for several minutes before crashing. Others, it crashes quickly with this panic:

panic: thread 'main' panicked at 'Entity does not exist'

The full log of my run, with Bevy set to debug mode and the system ambiguity checker added, can be found here. I can't pin down an easy reproduction even in my own game--it just seems like things crash after a while and I don't know why. If I'm tracing the panic back correctly to the system in question, it isn't immediately obvious to me that it's accessing despawned entities.

I'm seeing lots of this in the log:

�[2mMar 24 10:46:27.784�[0m �[34mDEBUG�[0m bevy_ecs::system::commands: Failed to despawn non-existent entity 271v1

I'm not sure where this is happening, but this is logging on debug. I'm also not sure how to trace back from this failing command invocation, to whatever system originated it. Obviously I want to do something about these failed despawns--I just don't know how.

What you expected to happen

Not panicking would be nice. as would some mechanism for tracing back from the panic to the specific command that caused it. Maybe some sort of no-op remove (I.e. "remove this component, but don't panic if the entity doesn't exist") would be nice too, though maybe I'm hitting a soundness bug somewhere that shouldn't be papered over by no-op commands. :)

What actually happened

Panics at random times. It's always when interacting with a specific subsystem of my game, but never in response to a specific action type or at a transition point.

Additional information

Happy to provide any, just let me know how to turn logging up to 11. :)

[alice-i-cecile]

This discussion hints at a similar bug, introduced in #1471. I expect @cart will be merging a fix shortly, but until then does the behaviour go away if you revert to before that PR was merged?

[ndarilek]

Ugh, I'm now relying on reliable change detection, so I can't revert that. I'll wait for a fix. and see if this goes away. But something similar happened on 0.4, so it's possible these are different issues. I didn't log because I'd hoped the ECS rewrite would nuke it from orbit, but the behavior is the same.

[alice-i-cecile]

This does not appear to be the issue in #1743. Seems like they are attempting to insert a component into a non-existent entity. This should be an error as it has real implications for app state (unlike removing components from non-existent entities or despawning non-existent entities, which we have previously agreed should not be errors due to Command synchronization complexity).

From #1748 :) Perhaps add in a check to see if the entity exists before issuing the component insertion command? Failing that, you could write a custom command that checks if the entity exists before trying to insert into it.

Perhaps we should be batch processing commands and always running component insertion before entity deletion, but that's a long way off.

[cart]

Perhaps we should be batch processing commands and always running component insertion before entity deletion, but that's a long way off.

Maybe we need to do command commits in a way that respects system dependencies?

[cart]

Ah wait i think we already do because we topologically sort the "parallel system" list.

[cart]

I'm thinking a simple remove_system.system().after(AddSystemLabel) should resolve this

[alice-i-cecile]

Maybe we need to do command commits in a way that respects system dependencies?

Yeah, talking with @BoxyUwU about this has convinced me that commands should be handled in the same order as the systems that generated them in order to keep the mental model clear.

[Ratysz]

Ah wait i think we already do because we topologically sort the "parallel system" list.

This is correct.

Yeah, talking with @BoxyUwU about this has convinced me that commands should be handled in the same order as the systems that generated them in order to keep the mental model clear.

Applying command buffers in the exact order of the systems that issued them is not possible unless we forbid parallelization: e.g., "order" doesn't make sense for systems A and B where A started before but ended after B. And timestamping and sorting all individual commands by default will most definitely have perf implications.

[mockersf]

Obviously I want to do something about these failed despawns--I just don't know how.

From my understanding, the issue is that there's no way to trace back the failing command to which system added it, making it hard to debug system order

[ndarilek]

Yeah, system order would be tough, because in this case it may be across plugin boundaries. So I'm not even sure what that means or how it would help here. Not sure to what extent this is orthogonal, but I'd love some sort of trace logging where commands are annotated with whatever system triggered them. Is that a tracing span? It'd be nice to grep the log for these failed despawns so I can track them back to whatever system created the entities. Right now my logs tell me that the entity failed to despawn, but not even debug-level lets me know what created them in the first place. And I'm not sure if these are the entities in question, but I don't know that I have the tooling to fix the issue and find out. Killing performance would be fine for that use case, since it'd be rarely used and more of an absolute last option.

[mockersf]

#846 may be relevant here.

With the new ordering of systems, this would be even more useful

[cart]

Im thinking this this issue isn't really something we can solve in the next day (and system ordering/restructuring logic is a workaround), so I'm removing this from the 0.5 milestone. We can add it back if thats unpopular or if I missed something important.

[alice-i-cecile]

Agreed: I'm much less concerned now that we understand what's going on better.

[ndarilek]

Sorry, I'm fine with pushing this past 0.5, but there's a workaround? I'm not clear on what it is. I seem to be despawning a bunch of entities that I have no way of knowing where they were spawned, and I don't know what to reorder much less which order to put things in. This does seem to be a bit of a corner case, so by all means don't delay the release, but if a workaround for my current situation was mentioned here, I must not be smart enough to have spotted it. :) Is the workaround just to brute-force reorder systems touching this particular component until my crashes stop? Thanks.

[edisno]

This is biting me hard also, and I have not yet been successful in reordering systems to avoid the as of now dreaded "Entity does not exist" crash. As a temporary workaround could this somehow be made into a non-fatal error?

[ndarilek]

Sorry for the noise, but this has bitten me twice in the last hour on two different systems. The weird thing is that it seems to happen when things are despawned, and with operations that could safely fail if the entity doesn't exist. I.e. if I'm tweaking something's name, and that thing is gone because a) the player destroyed it or b) the entire game was reset, then it's absolutely fine for that thing to fail in a way that doesn't toast the entire process.

Maybe the ambiguity-checker could help, but that seems like overkill for situations where I don't care if this fails. Could it just be made a non-panic, maybe log it at some high level and move on?

[alice-i-cecile]

Related to #2581.

[alice-i-cecile]

Closing; there's more specific issues for remaining improvements.