implementing state_timeout in AshStateMachine
Just had a look at https://github.com/ash-project/ash_state_machine/blob/v0.1.4/test/ash_state_machine_test.exs
Is there an option similar to :state_timeout from
https://www.erlang.org/doc/man/gen_statem.html#type-timeout_event_type
The use case is - if one state doesn't get a new transition within
:state_timeout seconds, it doesn't keep waiting foreverGitHub
ash_state_machine/ash_state_machine_test.exs at v0.1.4 · ash-projec...
Finite State Machine extension for Ash.Resource. Contribute to ash-project/ash_state_machine development by creating an account on GitHub.
4 Replies
So depending on how long you want your timeout to be (and how restart robust) I see you have two main options.
1. In your actions that move into a timeoutable state you add a change which calls
:timer.apply_after/4 (https://erlang.org/doc/man/timer.html#apply_after-4) to invoke another action which moves it into the timeout state if it hasn't succeeded yet.
2. In your actions that move into a timeoutable state you add a change which queues a job for later execution with a durable queue (eg Oban https://hexdocs.pm/oban/Oban.html#module-scheduling-jobs)
A variation on option 2 might be to just have an oban job that runs every n minutes which checks to see if there are any records that have been in the timeoutable state for longer than expected (eg expr(state == :waiting && updated_at < ago(5, :minute)))Keep in mind, ash_state_machine is not starting genservers.
Unless you’ve got your actions doing that.
It uses whatever data layer you’re using in the resource.
Id probably use
ash_oban with a trigger on how long it’s been waiting, but that’s only good for things longer than a minute, generally
Which is basically #2 above but with ash_oban.If the exact duration of the timeout is relevant to the correctness of your application, you may also consider setting a timestamp attribute on your resource when entering the timed state and validating that it is within the allowed offset in actions relevant for that state.
This is not mutually exclusive with the aforementioned methods for executing other actions/cleanups at some point after that duration has elapsed.
Some of the broader ideas make sense. I'll try it out to understand better. 🙂