Panic calling DynamicScene::write_to_world with MapEntities and ComponentHooks

[mrchantey]

Bevy version

0.14.0

What you did

• call DynamicScene::write_to_world with two components:
  1. One that uses MapEntities
  2. One that calls world.commands().spawn_empty() in ComponentHooks::on_add

What went wrong

Panics at bevy_ecs::entity::Entities::verify_flushed, traced back to scene::write_to_world

thread 'main' panicked at C:\work-ref\bevy\crates\bevy_ecs\src\entity\mod.rs:582:9:
flush() needs to be called before this operation is legal

Additional information

I dont know enough about the ecs internals to understand whats happening, possibly commands from the DeferredWorld in ComponentHooks::on_add are being called at an inappropriate time?

Full reproducible

use bevy::ecs::entity::MapEntities;
use bevy::ecs::reflect::ReflectMapEntities;
use bevy::prelude::*;

#[derive(Default, Component, Reflect)]
#[reflect(Component)]
struct CompA;
#[derive(Component, Reflect)]
// #[reflect(Component)]             // OK
#[reflect(Component, MapEntities)]   // Breaks
struct CompB(pub Entity);

impl MapEntities for CompB {
  fn map_entities<M: EntityMapper>(&mut self, entity_mapper: &mut M) {
    self.0 = entity_mapper.map_entity(self.0);
  }
}

fn main() {
  let mut app = App::new();
  app.register_type::<CompA>().register_type::<CompB>();
  let world = app.world_mut();
  world
    .register_component_hooks::<CompA>()
    .on_add(|mut world, _, _| {
      world
        .commands()
        .spawn_empty();
    });
  world.spawn((CompB(Entity::PLACEHOLDER), CompA));

  let scene = DynamicScene::from_world(world);
  scene.write_to_world(world, &mut default()).unwrap();
}

[mrchantey]

looks related to #14465

[jrobsonchase]

Can confirm - this is almost identical to #14465. In both cases, observers or hooks are able to create pending entities which aren't getting flushed before an operation is attempted which requires a flush in advance.

Still trying to figure out the best place to put the flush for this one.

[jrobsonchase]

Maybe this is more of an issue of SceneEntityMapper not upholding the Entities flushing contract. Could stick a world.flush_entities() at the start of SceneEntityMapper and call it good?

Still seems like observers are able to put the Entities into an unexpected needs-flushing state that should be addressed though.