Surprising system order when changing the state mid-frame

[hayashi-stl]

Bevy version

0.6.1

Operating system & version

Ubuntu 20.04

What you did

I have 3 systems: in_state_b, change_state, and on_state_change, which should update in that order. The first one should update only in state B, and the last one should update only when entering state B.

use bevy::prelude::*;

#[derive(Clone, Copy, PartialEq, Eq, Debug, Hash)]
enum AppState {
    A,
    B,
}

fn main() {
    App::new()
        .add_state(AppState::A)
        .add_system_set(
            SystemSet::on_enter(AppState::B).after("change").with_system(on_state_change)
        )
        .add_system_set(
            SystemSet::on_update(AppState::B).label("b").with_system(in_state_b)
        )
        .add_system(change_state.label("change").after("b"))
        .run();
}

fn change_state(mut state: ResMut<State<AppState>>) {
    println!("change_state");
    state.set(AppState::B).ok();
}

fn on_state_change() {
    println!("on_state_change");
}

fn in_state_b() {
    println!("in_state_b");
}

What you expected to happen

The following output:

change_state
on_state_change

What actually happened

The following output:

change_state
on_state_change
in_state_b

which seems to violate the ordering constraint.

Additional information

I suspect this may be intended behavior, seeing that fn should_run_adapter in src/schedule/state.rs returns the CheckAgain variants of ShouldRun. If it is intended, it would be nice to document.

[maniwani]

Seems like a duplicate of #3293 (although the name of this issue is better). See this comment.

Basically, on_update gets run immediately after on_enter regardless. I don't think it's "intended" behavior, but the fix is most likely going to be part of a larger rework to run criteria.

[alice-i-cecile]

Fixed by #7267.