`Result::unwrap()` on an `Err` value: StateAlreadyQueued'

[GetAGripGal]

Bevy version

0.8

Relevant system information

OS: Windows 11

What you did

I attempted to set change my gamestate like so:

// Change the state
if *state.current() != event.0 {
    state.set(event.0).unwrap();
}

What went wrong

Doing so crashes the game with the following error:
Result::unwrap()` on an `Err` value: StateAlreadyQueued'

Additional information

The current workaround i took was to use State::overwrite_set instead like so:

// Change the state
if *state.current() != event.0 {
    // Using [`State::overwrite_set`] instead of [`State::set`] to cirvumvent the 'Aleady Scheduled' bug. 
    state.overwrite_set(event.0).unwrap();
}

Edit: To clarify, this system is only being called once per frame and the state isn't currently being changed anywhere else in the code.

[mockersf]

This error means that you already changed the state in this frame. The overwrite_* method is made to ignore ongoing transitions.

Without more context, this seems to work exactly as expected 👍

[klemola]

@mockersf I'm getting this panic after updating to version 0.8, without any code changes related to states or system sets.

When I print the current app state at the app_state.set call site, the current one is not the one I'm scheduling. Logically I can't think of a way my code could possibly schedule the state twice 🤔

app state ResMut(State { transition: Some(Entering(A, B)), stack: [B], scheduled: None, end_next_loop: false })

Let's call the states A, B, and C by their logical order. I'm trying to transition to state C, and as you can see from above, C can't be found from the current state as scheduled or as the current state.

Edit: The state change is scheduled from a system that runs at SystemSet::on_enter. I also believe that A->B and B->C transitions occur on the same frame/update.

[mockersf]

The error is saying there is already a transition ongoing, which you can see by transition not being None.

It doesn't have the best name, it's StateAlreadyQueued as in "there's already a new state queued", not "the state you're trying to set is already queued"

[klemola]

The error is saying there is already a transition ongoing, which you can see by transition not being None.

It doesn't have the best name, it's StateAlreadyQueued as in "there's already a new state queued", not "the state you're trying to set is already queued"

Ah, I see. Thanks for the clarification! Still, how can the SystemSet::on_enter system of state B run before the transition is completed? Has something changed in 0.8 that caused this panic, as it seems to me?

[mockersf]

I think it's a bug that it was accepted before. #4890 is probably the source of your panic.

setting a new state in on_exit was causing issues so controls where added and it seems those controls also impact on_enter

[klemola]

I think it's a bug that it was accepted before. #4890 is probably the source of your panic.

Yeah! That must be it. I'll see if there's a better way to handle the three states, maybe by making state B redundant.

[thephet]

I am having a similar problem. Code was fine in 0.7 but now in 0.8 I get the same error.

You can see here the system that handles changing the states (turns in my case). It is only 45 lines:

https://github.com/thephet/BevyRoguelike/blob/main/src/systems/end_turn.rs

[GetAGripGal]

This error means that you already changed the state in this frame. The overwrite_* method is made to ignore ongoing transitions.

Without more context, this seems to work exactly as expected 👍

I am not changing the state anywhere else in the code and the system is only called once per frame. The code worked fine in 0.7 but broke after 0.8.

[neocturne]

I'm seeing this error when trying to change the state again in a system running on_enter() on 0.8, which didn't happen on 0.7. When moving the system to on_update(), changing the state again does work on 0.8 (but it is less convenient for my usecase). Using the overwrite_* methods might be a good enough solution though.