elsa-workflows / elsa-workflows/elsa-core
Workflow instance retry issue
- Dominant language
- C#
- Stars
- 7.9k
- Forks
- 1.5k
- Avg merge
- 15h 22m
- Merged PRs (30d)
- 114
Description
I have a workflow with some activities and some customs. One of the custom activity just does return Fault();
I'm using HangfireDispatcher. What I see is that if I press retry on the Elsa studio dashboard or using the retry API, the workflow status changes to Running but with a red label. Then, a warning appears in console of the Elsa server:
```
warn: Elsa.Services.Workflows.WorkflowInstanceExecutor[0]
Did not run workflow f8575e9b296b4e75936eea2b1a6fba93 for activity 1b87793b-f7f6-4793-a377-de43550f2e47 because the workflow is not blocked on that activity nor is that activity scheduled for execution
```
If I check my workflow, the activity that is shown in the log is not the Faulted one, but the first of the workflow, so it fails. As I'm using HangfireDispatcher, a job is created and it shows the wrong activityId as an argument, matching the one that the elsa warning log shows. So, it seems that the dispatcher is not sending the correct activityId to revive. Looking into the code, seems that CurrentActivity is null here and, when this happens, it gets the first activity of the workflow:

When my workflowinstance is Faulted, I can see in database that there is a Faulted activity in the workflowinstances row of my workflow. Then, when retrying, the database shows what is expected to be scheduled right:

This is the ActivityId of the faulted Activity. But as I said, it dispatches the first of the workflow.
Because Elsa has a server down protection, if I just restart Elsa server, the workflow is auto dispatched with the faulted activity right and the execution continues.
Contributor guide
Research direction
Start with the HangfireDispatcher retry path used by Elsa Studio or the retry API, then compare the persisted faulted ActivityId in workflowinstances with the job argument and WorkflowInstanceExecutor warning. Done means retry dispatches the faulted activity rather than the first activity and the workflow resumes without requiring a server restart.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100