Skip to content

bevy_ecs: forward type_id in InfallibleSystemWrapper #18931

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

jakobhellermann
Copy link
Contributor

similar to #12030

Objective

bevy_mod_debugdump uses the SystemTypeSet::system_type to look up constrains like (system_1, system_2.after(system_1)). For that it needs to find the type id in schedule.graph().systems()

Now with systems being wrapped in an InfallibleSystemWrapper this association was no longer possible.

Solution

By forwarding the type id in InfallibleSystemWrapper, bevy_mod_debugdump can resolve the dependencies as before, and the wrapper is an unnoticable implementation detail.

Testing

  • cargo test -p bevy_ecs
    I'm not sure what exactly could break otherwise.

`bevy_mod_debugdump` uses the `SystemTypeSet::system_type` to look up
constrains like `(system_1, system_2.after(system_1))`.
For that it needs to find the type id in `schedule.graph().systems()`

Now with systems being wrapped in an `InfallibleSystemWrapper` this
association was no longer possible.
@@ -30,6 +30,10 @@ impl<S: System<In = ()>> System for InfallibleSystemWrapper<S> {
self.0.name()
}

fn type_id(&self) -> core::any::TypeId {
Copy link
Contributor

@SpecificProtagonist SpecificProtagonist Apr 26, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
fn type_id(&self) -> core::any::TypeId {
/// Type id of the wrapped system.
fn wrapped_type_id(&self) -> core::any::TypeId {

Let's not shadow <InfallibleSystemWrapper as Any>::type_id with a different meaning (previously using the same name was fine, as it always returned the same result).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we rename the method, I'd vote for system_type because not every System is a wrapper. It also aligns with SystemSet::system_type

@chescock
Copy link
Contributor

Do you want to add a unit test that verifies that the type ids are the same, with a comment that bevy_mod_debugdump is relying on it? That could reduce the risk of it regressing again.

Alternately, I think Bevy is internally matching things up using System::default_system_sets() and IntoSystemSet::into_system_set(). I don't know whether it's feasible for you to use SystemSets instead of type ids, but if you can, then the fact that they're used internally should make them more reliable.

@ickshonpe ickshonpe added the A-ECS Entities, components, systems, and events label Apr 29, 2025
Copy link
Contributor

@hymm hymm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a little weird that type id won't return the actual type id, but I think this fix makes sense. The internal uses are just to identify apply_deffered systems and getting systems for system stepping. And I can't think of any ways this would mess things up for external consumers.

@jakobhellermann
Copy link
Contributor Author

Alternately, I think Bevy is internally matching things up using System::default_system_sets() and IntoSystemSet::into_system_set(). I don't know whether it's feasible for you to use SystemSets instead of type ids, but if you can, then the fact that they're used internally should make them more reliable.

Oh nice, that works as well:

    fn system_of_system_type(&self, set: &dyn SystemSet) -> Option<NodeId> {
        self.graph.systems().find_map(|(id, system, _)| {
            let is_system_set = system.default_system_sets().iter().any(|s| s.0 == set);
            is_system_set.then_some(id)
        })
    }

In that case I don't need this PR at all and can release bevy_mod_debugdump with bevy 0.16.0. I can close this PR then, unless there are other reasons to want this.

@janhohenheim janhohenheim added the S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it label May 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ECS Entities, components, systems, and events S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants