Removing Components from inside guarded block in hook still results in ECS error logs

[still cloak]

I'm removing components like so in the on_replace and on_remove hooks for a component. They're guarded and I'm checking for the existence of the entity beforehand.

            if let Ok(mut entcmds) = world.commands().get_entity(ent) {
                entcmds.remove::<BackgroundColor>();
                entcmds.remove::<ImageNode>();
            }

This still results in ECS Error logs:

2025-05-03T17:04:32.366610Z WARN bevy_ecs::error::handler: Encountered an error in command `<bevy_ecs::system::commands::entity_command::remove<bevy_ui::widget::image::ImageNode>::{{closure}} as bevy_ecs::error::command_handling::CommandWithEntity<core::result::Result<(), bevy_ecs::world::error::EntityMutableFetchError>>>::with_entity::{{closure}}`: The entity with ID 631v429 does not exist (index has been reused or was never spawned)

Is there something I'm doing wrong; I'd expect to just not enter the conditional block if the entity doesn't exist.

[boreal grail]

if you have world you can remove it without it being through commands

commands will be deferred to the next sync point, if there is a command earlier in the queue that removes the entity, then it will cease to exist before the component removal commands

https://docs.rs/bevy/latest/bevy/prelude/struct.Commands.html#method.get_entity

Returns the EntityCommands for the requested Entity if it exists.
This method does not guarantee that commands queued by the returned EntityCommands will be successful, since the entity could be despawned before they are executed.

[still cloak]

So even if it does cease to exist, I would assume that the if let Ok() ... get_entity() would return Error right? Then we wouldn't even attempt to remove the BackgroundColor etc.

I'm trying to identify what changed between 0.15 when this worked fine and 0.16

Realistically what can you do for these kinds of errors if they're unavoidable? Commands can be invoked from any point in the schedule etc. so it's not a system ordering thing. I'd like to avoid my logs being polluted by errors from effectively idempotent commands like this