Best way to get the previous DecisionTaskCompleted Id from a specific activity

Community Support
1

I have the following scenario:

My workflow has several activities, some are running in sequence and others are running in parallel

A1 ---A2 --- A4 --- A5 ------ A7
      \                 /
         A3 --- A6----

A3 and A6 are running parallel with A2, A4 and A5. A7 is waiting for both branches to complete.

I have implemented this flow using the DSL sample found in github. So far, so good.

Now … I have this case where I have to restart the flow from a specific point. Let’s say A5. It means I want to rerun the A5 activity and all the activities after that one. According to the Docs I need to use the CLI for that, so I need to provide the eventId for the last DecistionTaskCompleted. The thing is, I’m trying to figure out the best way to do so.

So far my best guess is to traverse the whole history array and just get the last DecisionTaskCompleted Id before the targeted activity I want to rerun, but that solution doesn’t seem to be the most reliable. Is there a better option?

PS: Using the CLI argument “LastDecisionCompleted” does’t work because A5 might be a successful activity

2

If restarting flow is a business requirement I would make it part of the workflow definition and would not try to hack using glow level mechanisms like the reset.

In your DSL AST you can start from any node based on a signal workflow receives.

3

Thanks for answering maxim!

Can you give me more details about how to address this case?

I suppose you refer to the method: “SignalWithStartWorkflow”. right?

How can I manage to get the previous returns values from the activities I’m skipping? Let me explain this in a better way. Let’s say I have this workflow that I want to restart/rerun

A(-s) — B(-s) — C(-r) ---- D(-r) — End
s: skip
r: rerun

Here I want to restart this workflow from point C. So I want to skip the activities A, an B, but still getting their return values (from the first run). So that they can be received by activity C and probably activity D as well.

That’s something I could notice the restart CLI option was doing. But It’s not very clear how I can achieve the same behavior using signals. Do you have some method in mind?

4

I’m still confused about the requirements. What is the reason to retry your workflow from C? Is it normal business logic of reexecuting activities from any place or it is to deal with some unexpected situations?

5

Unexpected Situations:
The other day we had this issue where the team responsible for service C told us to rerun the request again since they were presenting issues and the 200 OK we got was a false positive.

So we did it manually, They were just a few requests affected so we could do it without problems. But now we wonder what would happen when we got 1000 affected requests and we had to do it again.

That’s why we were trying to find a way to get (in a programmatic way) the event id to use in the CLI.

6

I see. Then the reset is the best way to achieve your requirements. And parsing history to find out the eventId of DecistionTaskCompleted event is the only option.

We have plans to add additional types of reset and retry from a specific activity type is one of them. I filed an issue for easier tracking.