Hierarchy example panics after a second or two

[rparrett]

Bevy version

Latest bevy main (post-new-renderer) (ffecb05)
Latest bevy main pre-new-renderer (de8edd3)
Also this random commit (94db017)

Operating system & version

m1 mac (macos 12)

What you did

cargo run --example hierarchy or
cargo run --example hierarchy --release

What actually happened

The example runs for two seconds and then panics

Additional information

RUST_BACKTRACE=1 cargo run --example hierarchy --release
    Finished release [optimized] target(s) in 0.09s
     Running `target/release/examples/hierarchy`
thread 'Compute Task Pool (1)' panicked at 'Attempting to create an EntityCommands for entity 3v0, which doesn't exist.', examples/ecs/hierarchy.rs:114:22
stack backtrace:
   0: rust_begin_unwind
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/panicking.rs:517:5
   1: core::panicking::panic_fmt
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/core/src/panicking.rs:100:14
   2: bevy_ecs::system::commands::Commands::entity
   3: core::ops::function::impls::<impl core::ops::function::FnMut<A> for &mut F>::call_mut
   4: <bevy_ecs::system::function_system::FunctionSystem<In,Out,Param,Marker,F> as bevy_ecs::system::system::System>::run_unsafe
   5: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
   6: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
   7: async_task::raw::RawTask<F,T,S>::run
   8: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
   9: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  10: std::thread::local::LocalKey<T>::with
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread 'main' panicked at 'task has failed', /Users/robparrett/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/async-task-4.0.3/src/task.rs:368:45
stack backtrace:
   0: rust_begin_unwind
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/panicking.rs:517:5
   1: core::panicking::panic_fmt
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/core/src/panicking.rs:100:14
   2: core::panicking::panic_display
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/core/src/panicking.rs:64:5
   3: core::option::expect_failed
             at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/core/src/option.rs:1638:5
   4: <async_task::task::Task<T> as core::future::future::Future>::poll
   5: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
   6: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
   7: async_task::raw::RawTask<F,T,S>::run
   8: async_executor::LocalExecutor::try_tick
   9: bevy_tasks::task_pool::TaskPool::scope
  10: <bevy_ecs::schedule::executor_parallel::ParallelExecutor as bevy_ecs::schedule::executor::ParallelSystemExecutor>::run_systems
  11: <bevy_ecs::schedule::stage::SystemStage as bevy_ecs::schedule::stage::Stage>::run
  12: <bevy_ecs::schedule::Schedule as bevy_ecs::schedule::stage::Stage>::run
  13: bevy_winit::winit_runner_with::{{closure}}
  14: <winit::platform_impl::platform::app_state::EventLoopHandler<T> as winit::platform_impl::platform::app_state::EventHandler>::handle_nonuser_event
  15: winit::platform_impl::platform::app_state::Handler::handle_nonuser_event
  16: winit::platform_impl::platform::app_state::AppState::cleared
  17: winit::platform_impl::platform::observer::control_flow_end_handler
  18: <unknown>
  19: <unknown>
  20: <unknown>
  21: <unknown>
  22: <unknown>
  23: <unknown>
  24: <unknown>
  25: <unknown>
  26: <unknown>
  27: <unknown>
  28: winit::platform_impl::platform::event_loop::EventLoop<T>::run_return
  29: winit::platform_impl::platform::event_loop::EventLoop<T>::run
  30: winit::event_loop::EventLoop<T>::run
  31: bevy_winit::run
  32: bevy_winit::winit_runner_with
  33: core::ops::function::Fn::call
  34: bevy_app::app::App::run
  35: hierarchy::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[rparrett]

Oops, fork was a bit out of date. Re-testing on latest main.

[rparrett]

Is it normal behavior for despawn to not update hierarchies?

Should this example use despawn_recursive for both despawns?

I'm a bit confused by this test, which is doing some despawning, but then seemingly not asserting anything particularly interesting afterwards.

https://github.com/bevyengine/bevy/blob/main/crates/bevy_transform/src/hierarchy/hierarchy_maintenance_system.rs#L156.

[mockersf]

Is it normal behavior for despawn to not update hierarchies?

Yup, despawn doesn't have any knowledge about hierarchies...

This is one of the case not matched by the hierarchy maintenance, the child entity has been removed but we have no knowledge of it's parent before, so we can't clean it from the Children component on the parent.

Should this example use despawn_recursive for both despawns?

despawn_recursive works in that case because this command knows how hierarchies works, and look for the parent of the entity at despawn time. It would fix the failure 👍

[rparrett]

This isn't a super major issue, so I'm happy to pass on it if we want to slap E-Good-First-Issue on it.

[rparrett]

Thanks @cryscan