Handling Workflow Failures with On-Demand Retryable Activities in Effect Typescript Library
On the topic of handling workflow failures (re clusterHandling Workflow Failures and Replays in Effect Typescript Library), I find that my typical development lifecycle is a constant iteration between:
1. run of a potentially long running workflow,
2. discovering new errors due to my code being still WIP,
3. fixing the errors
Everytime I reach end of step 3, I have to retrigger a whole new workflow run that can potentially last quite long or be costly because I am repeating the execution of activities that had previously succeeded. I can go and edit the database directly to trick the workflow into retrying the failed activities (involves updating rows in
Using
1.
pause the workflow when an activity fails
2.
see in the logs the error that occurred in the activity
3.
correct the code
4.
trigger a retry of the failed activity
I'm attaching the code in the thread
for those of you interested. I am looking for feedback, maybe if you can think of something that could go wrong with this approach. I would love to see something like this baked in the Workflow / Activity primitives of 
1. run of a potentially long running workflow,
2. discovering new errors due to my code being still WIP,
3. fixing the errors
Everytime I reach end of step 3, I have to retrigger a whole new workflow run that can potentially last quite long or be costly because I am repeating the execution of activities that had previously succeeded. I can go and edit the database directly to trick the workflow into retrying the failed activities (involves updating rows in
cluster_messages and deleting rows in cluster_replies) but I am not a big fan (error prone & not recommended in production).Using
DurableDeferred I came up with an "on demand" retryable activity. The idea is to be able to:1.
pause the workflow when an activity fails2.
see in the logs the error that occurred in the activity3.
correct the code4.
trigger a retry of the failed activityI'm attaching the code in the thread
for those of you interested. I am looking for feedback, maybe if you can think of something that could go wrong with this approach. I would love to see something like this baked in the Workflow / Activity primitives of @effect/workflow 
