I tend to agree with OPs reasons for using Oban.
Oban: Essential for job persistence, concurrency control, and “Resume from failure” logic.
In fact, I have found myself using Oban as my state machine library of choice since its states and arg persistence and retry handling cover pretty much all my uses cases. Before I found myself adding a “status” enum with only minor variation in values and repetitive transition logic to various contexts/schemas. Bringing in a new dep just to handle that kind of thing seemed unnecessary, but as I went to abstract it myself I realized I was recreating a bunch of APIs I already had at my disposal in Oban. So I started to lean more on it and most of that stuff just became worker config, leaving only the need to enqueue jobs with the appropriate args. Logic has much better SoC because the schemas now only express states that are actually specifically meaningful to the domain, and all the generic “error” “pending“ etc stuff is hidden away and protected with much better guarantees than I ever managed to maintain. And that’s before using any of the Pro features like workflows. So it’s hard for me to imagine the downside to using Oban for something like this.
