alt Hacker News> If any of the required subtasks fail, you don’t do the side effects. You ROLLBACK.
I'm afraid I am still not seeing the advantage here: the subtasks that can fail are IO almost exclusively. If the email is already sent when the DB update fails, that email can't be recalled.
Other than hash/signature verification, just what sort of subtasks did you have in mind that can fail and aren't IO?
If your task fails, yet you sent an email that it succeeded, that is bad. You should wait until all your subtasks finish before sending the email.
Async subtasks typically ARE i/o, whether over a network or not.
The email shouldn't be sent if the DB update fails. The whole point is you wait until everything succeeds, before sending the email.
If your subtasks cause you to write some rows as if they succeeded, but subsequent subtasks fail, that is bad. You have to rollback your changes and not commit them.
If you charge a user even though they didn't get the thing they paid for, that's bad. Yes you can refund them after a dispute, but it's better not to have charged them in the first place.
The point is this: any subtasks that can cause your main task to fail should be processed BEFORE any subtasks that cannot cause your main task to fail.