Despawn replaced linked-spawn related entities when applying a scene

[mansiverma897993]

Applying a Scene to an existing entity (e.g. apply_scene) previously replaced and orphaned the entity's pre-existing related entities. For UI widgets this left the replaced subtree lingering in the world as root nodes: re-applying a FeathersListView scene patch produced a 'ghost' of the list content at the top of the window and a viewport scrollbar, and every re-apply leaked another orphaned subtree.

Now, when an applied scene defines related scenes for a relationship, the entity's pre-existing related entities are despawned first - but only for relationships with linked-spawn semantics (such as Children), where the relationship target already owns the lifecycle of its related entities. Relationships without linked-spawn semantics still orphan, to avoid despawning entities the target does not own.

Fixes #24939

[viridia]

There is a workaround that lets you do this without modifying BSN, which I use in bevy_reactor:

        parent.queue_apply_scene(bsn! {
            bundle_template(|context| {
                context.entity.despawn_children();
                Ok(())
            })
            Children [
                {(self)()}
            ]
        });

I have a wrapper which automatically does this for dynamic sub-trees of my ui hierarchy.

As far as changing the built-in behavior of scene spawning, you'll have to talk to @cart about this - it's something that has been discussed extensively on the discord.

[alice-i-cecile]

Have you tested this manually with the reproduction code in the linked issue?

[mansiverma897993]

@alice-i-cecile how I can join discord of bevy for further discussion of this issue ?? Do I need to do any test ?

[alice-i-cecile]

https://discord.com/invite/bevy :) #24939 lays out a nice reproduction of the problem that you can run; usually I just temporarily modify the hello_world example and run it while developing this sort of fix for Bevy.

[viridia]

I would strongly advise consulting with @cart before going ahead with this, as it may conflict with his vision of how this stuff is supposed to work. Specifically: In the BSN discussions from several months back, I had requested a new API method which would have this behavior (despawn old children before replacing with new), and he recommended using the workaround that I posted above. So the implication is that the current behavior is both known and intentional.