Make state methods panic on missing StatePlugin

[MiniaczQ]

Objective

• Fixes: State API should panic when missing StatePlugin #14237
• Fixes Improve error message when StatesPlugin is missing #14151

Solution

• As described in the issue

Testing

• Ran the example from the issue
  

[benfrankel]

Small PR, one nit.

[mockersf]

Could you check the stack trace, and how easy it is to find where the issue comes from? Could track_caller help?

Also, what does it mean to "install" a plugin? I prefer the error message from #14160

[mockersf]

I would also prefer to not have a hard dependency on the plugin, but on what it's adding. If someone decides to rewrite the plugin changing a few things but still setting up all the machinery, it should still work. #14160 is better for that

[MiniaczQ]

I would also prefer to not have a hard dependency on the plugin, but on what it's adding. If someone decides to rewrite the plugin changing a few things but still setting up all the machinery, it should still work. #14160 is better for that

Agree to disagree, most of the machinery is in the app methods. StatePlugin only adds StateTransitions to startup and main schedules and register the core state set. The only valid use case for swapping just the plugin would be to remove StateTransitions from startup, which doesn't sound bad, but can cause 3rd party crates to work incorrectly if they relied on this.

So replacing the machinery would require replacing both, the plugin and the methods. And that's still at the risk of breaking 3rd party crates

[MiniaczQ]

Could you check the stack trace, and how easy it is to find where the issue comes from? Could track_caller help?

I think it's plenty readable as is:

With [track_caller]:

[alice-i-cecile]

I would also prefer to not have a hard dependency on the plugin, but on what it's adding. If someone decides to rewrite the plugin changing a few things but still setting up all the machinery, it should still work. #14160 is better for that

In addition to the feedback above; this will also be much harder to maintain. I don't think we have a clear / stable enough set of invariants to make this feasible right now.

[mnmaita]

Is this still relevant now that #14160 was merged? @alice-i-cecile

[alice-i-cecile]

I'd like to avoid panics unless absolutely essential, and I think that #14160 is an adequate solution to this problem. Closing.