AshOban and AshStateMachine
Im using AshStateMachine to keep track of a state of a resource and ensure they transition correctly like
note: the state machine does not allow jumping from
However the state of the resource is determined by an external API, which I need to poll once a minute.
I thought of doing this with AshOban, so I started to implement the change in the action, which the AshOban triggers every minute.
In the change for my resource I call the external API and I get the state back, which leads me to my question:
What do I do if the external state is now
I assume AshStateMachine will tell me, that I can't transition the resource to
Since the AshOban is executing a change that means I can't execute another action that will put the resource in the
I'm fairly new to Ash and Oban, so I might have missed something or my architecture for this entire operation should be different - maybe using a regular Oban worker in this case.
:created -> :processing -> :completednote: the state machine does not allow jumping from
:created to :completedHowever the state of the resource is determined by an external API, which I need to poll once a minute.
I thought of doing this with AshOban, so I started to implement the change in the action, which the AshOban triggers every minute.
In the change for my resource I call the external API and I get the state back, which leads me to my question:
What do I do if the external state is now
:completed but the resource in my DB has state :created, meaning I missed the :processing state? I assume AshStateMachine will tell me, that I can't transition the resource to
:completed.Since the AshOban is executing a change that means I can't execute another action that will put the resource in the
:processing state inside of that change, and then afterwards transition the resource to the :completed state, because then I will be running an action inside an action, which is not recommend, right?I'm fairly new to Ash and Oban, so I might have missed something or my architecture for this entire operation should be different - maybe using a regular Oban worker in this case.
Solution
State machines are supposed to be in charge of their own state. That's their whole reason for existing, they express the rules of what's possible and control transitions with an iron fist.
I think sourcing your state from outside the app kinda defeats the purpose here. Someone else is in control of these transitions, not you.
I would have to know more about the problem space to say anything else but I would start by asking myself if I need state transition logic on my end of things, or to just trigger some actions based on the current state
I think sourcing your state from outside the app kinda defeats the purpose here. Someone else is in control of these transitions, not you.
I would have to know more about the problem space to say anything else but I would start by asking myself if I need state transition logic on my end of things, or to just trigger some actions based on the current state
