Running `trigger` on an entity sometimes causes panic in `FixedUpdate` schedule but not in `Update`

[velvet gate]

I'm running into an issue with the following code

fn system(...) {
  if let Ok(mut cmd) = commands.get_entity(e) {
    cmd.trigger(SomeEvent);
  }
}

When this system is running on Update schedule, it works fine without any issues. However when I start using this under the FixedUpdate schedule, sometimes it run into Entity not found error and panic the app. This seems to happen randomly.

I thought the .get_entity function already does the check of making sure entity is there. Why does this behave differently between Update and FixedUpdate schedules.

[vernal elk]

Which schedule is the entity created with?

Commands executed this way aren’t synchronous, so you only check the entity exists at the point of sending the commands, but not when the commands are run, which could be creating a race condition

[velvet gate]

The entities are created in the FixedUpdate schedule. How does entity spawn schedule impact the despawn logic?

[steel crescent]

Update is after FixedUpdate, with a sync point in between
you need to order the system .after() whatever system spawns the entities

[velvet gate]

The error is complaining about entity got despawned already, how would scheduling the system after the spawn system resolve the issue?

[steel crescent]

if you explicitly schedule something before or after something else, there'll be an ApplyDeferred in the middle, which actually spawns the entities in Commands

[velvet gate]

I see. So in generally, if I encounter some errors in a system, then scheduling that system on a dedicated set and make that set after another set would avoid parallel systems run into conflict?