Registering a state using add_state does not create schedules, or they cannot be found later

[campbellcole]

Bevy version

0.10.0

[Optional] Relevant system information

If you cannot get Bevy to build or run on your machine, please include:

Tested with Rust versions:

• 1.70.0-nightly (15d090969 2023-03-21)
• 1.70.0-nightly (4a3c588b1 2023-03-14)
• 1.66.0 (latest stable version)

OS: NixOS 23.05.20230321.19cf008 (Stoat) x86_64
Kernel: 6.2.7-zen1

What you did

main.rs

fn main() {
    App::new()
        .add_state::<AppState>()
        ... // other plugins not related to this issue
        .add_plugin(player::PlayerPlugin)
        ...
        .run();
}

state.rs: AppState (I have tried both deriving and manually implementing States, neither works)

#[derive(Debug, Clone, Copy, Default, PartialEq, Eq, Hash)]
pub enum AppState {
    #[default]
    Loading,
    // Menu,
    Game,
    Paused,
}

impl States for AppState {
    type Iter = std::array::IntoIter<Self, 3>;
    fn variants() -> Self::Iter {
        [
            AppState::Loading,
            // AppState::Menu,
            AppState::Game,
            AppState::Paused,
        ]
        .into_iter()
    }
}

player.rs

pub struct PlayerPlugin;

impl Plugin for PlayerPlugin {
    fn build(&self, app: &mut App) {
        app.add_plugin(FpsControllerPlugin)
            .init_resource::<CollisionsDisabled>()
            .add_system(build_player.in_schedule(OnEnter(AppState::Game))) // the affected line
            .add_systems(
                (toggle_noclip, update_flyspeed, mouse_capture).in_set(OnUpdate(AppState::Game)),
            );
    }
}

What went wrong

The app crashes instantly upon startup, presumably as the build_player system gets registered:

    Finished dev [optimized + debuginfo] target(s) in 1m 43s
     Running `target/debug/raumblocken`
2023-03-25T09:07:59.242488Z  WARN wgpu_hal::vulkan::instance: Unable to find layer: VK_LAYER_KHRONOS_validation
thread 'main' panicked at 'Schedule OnEnter(Game) does not exist.', /home/campbell/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_app-0.10.0/src/app.rs:393:17
stack backtrace:
   0: rust_begin_unwind
             at /rustc/8be3c2bda6b683f87b24714ba595e8b04faef54c/library/std/src/panicking.rs:579:5
   1: core::panicking::panic_fmt
             at /rustc/8be3c2bda6b683f87b24714ba595e8b04faef54c/library/core/src/panicking.rs:67:14
   2: bevy_app::app::App::add_system
             at /home/campbell/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_app-0.10.0/src/app.rs:393:17
   3: <raumblocken::player::PlayerPlugin as bevy_app::plugin::Plugin>::build
             at ./src/player.rs:18:9
   4: bevy_app::app::App::add_boxed_plugin
             at /home/campbell/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_app-0.10.0/src/app.rs:764:9
   5: bevy_app::app::App::add_plugin
             at /home/campbell/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_app-0.10.0/src/app.rs:744:15
   6: raumblocken::main
             at ./src/main.rs:16:5
   7: core::ops::function::FnOnce::call_once
             at /rustc/8be3c2bda6b683f87b24714ba595e8b04faef54c/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Additional information

This seems similar to #7910 / #7911, but moving the .add_state call to the top of the call chain does not fix the issue. I looked at the add_state code and it indicates that the schedules are created immediately and should be available to the app after that point.

The only cause I can imagine for this is that states are not shared between plugins, which feels counterintuitive and I can't find that documented anywhere. Thanks for your time.

[campbellcole]

I figured out that this issue was being caused by the automatic imports in rust-analyzer choosing the wrong AppState import. The binary this app is running contains both a main.rs and lib.rs, and apparently these yield distinct types. Rather than importing the crate::state::AppState enum, it imported the raumblocken::state::AppState, while the plugins imported the crate version. Since the lib.rs version was registered, the plugins tried to use the crate version which had not been registered.

This was fixed by removing the lib.rs file, which I was only using for debugging. Another fix could be to manually change the <crate_name>::<...> import to a crate::<...> import.