Seems pretty similar to https://github.com/radioactive-labs/chrono_forge which is what I found when I typed in "rails durable execution patterns" into Google. Have you seen this and if so, how do you think it compares?
Congratulations on shipping this, I’m sure folks will find it useful!
The rails native way to do this is to track state in a db row and queuing “next step” jobs as the data changes. This can get verbose especially for smaller pass/fail workflows. However, I find this works better (not worse imo) in more complex workflows as the state is tracked, queryable, can be surfaced in UIs, and resumed “manually” in the event of an outage.
This looks useful. I've been exploring similar durable execution patterns in Go recently to avoid the complexity of Temporal for smaller workflows.
How does stepped_actions handle the state between steps? Does it persist to the DB after every single action to handle crash recovery, or is it more optimistic?
Yes, state is persisted to DB upon every change. Action exceptions are handled gracefully and natural part of the system, they simply fail the action. Crash recovery is build-in thanks to checksums and ActiveJob, if you're using the right adapter, like GoodJob or SolidQueue where crash recovery is guaranteed.
Seems pretty similar to https://github.com/radioactive-labs/chrono_forge which is what I found when I typed in "rails durable execution patterns" into Google. Have you seen this and if so, how do you think it compares?
Congratulations on shipping this, I’m sure folks will find it useful!
The rails native way to do this is to track state in a db row and queuing “next step” jobs as the data changes. This can get verbose especially for smaller pass/fail workflows. However, I find this works better (not worse imo) in more complex workflows as the state is tracked, queryable, can be surfaced in UIs, and resumed “manually” in the event of an outage.
This looks useful. I've been exploring similar durable execution patterns in Go recently to avoid the complexity of Temporal for smaller workflows.
How does stepped_actions handle the state between steps? Does it persist to the DB after every single action to handle crash recovery, or is it more optimistic?
Good luck with the launch
Yes, state is persisted to DB upon every change. Action exceptions are handled gracefully and natural part of the system, they simply fail the action. Crash recovery is build-in thanks to checksums and ActiveJob, if you're using the right adapter, like GoodJob or SolidQueue where crash recovery is guaranteed.