I agree on the GenServer part since wait time is less than a minute.
Nonetheless, this gives a good idea on how ash_oban and ash_state_machine work together.

Will manage the genserver for now

I think AshOban will not be the best case for this. I think you will want a GenServer handling the state of the resource, and transitioning from state to state. When a quiz is started (or perhaps resumed on reconnection) you can load up the relevant state machine and begin interacting with it. Generally speaking, less than one minute feedback loops aren’t the best fit for Oban/AshOban in my experience.

AshOban triggers can be triggered in one(or both) of two ways:

trigger :send_next_question do
  scheduler_cron "* * * * * *" # trigger for any matches every one minute
  where expr(state == :send_next_question)
end

...

# schedule the next invocation automatically
update :send_next_question do
  change run_oban_trigger(:send_next_question)
  # or in a custom change `AshOban.run_trugger`
end

For that latter case, we don’t have a run_trigger_later, but we could add one or you could hand roll one pretty easily. When you combine both of these, typically the scheduler_cron and where act as a backup in case something goes wrong triggering the actions. You can also only use the second strategy, and pass scheduler_cron nil to not automatically check for matches and trigger the action.

However, this is going to amount to a lot of database back and forth during what looks to be intended to be a pretty tight loop. Your user would likely have a better experience if the quiz flow was designed as a GenServer I think. I can see a case for having tooling for this kind of thing built into ash_state_machine, i.e some state machines should be statable, keep track of some in memory state, and have an accompanying module that handles state transitions in memory or something. Maybe