Thanks Maxim. I am reading history events but don’t see any method to get first WorkflowTaskFinishEventId. I am assuming while iterating the history, the first WorkflowTaskCompleted is " first WorkflowTaskFinishEventId". Is it correct understanding? How to get “id” ?. I noticed two methods getStartedEventId & getScheduledEventId. Which is the correct one?
Thanks Maxim. That’s helpful. The code captures one more case for getFirstWorkflowTaskEventID(). If EVENT_TYPE_WORKFLOW_TASK_COMPLETED doesn’t exist, can workflow be restarted EVENT_TYPE_WORKFLOW_TASK_SCHEDULED +1 ?
if e.GetEventType() == enumspb.EVENT_TYPE_WORKFLOW_TASK_SCHEDULED {
if workflowTaskEventID == 0 {
workflowTaskEventID = e.GetEventId() + 1
}
When trying to restart the workflow, getting response as run_id: “11c31eb2-d9fc-49b9-b84a-c32443bfd74a”. But in temporal UI that new runId is in failed state, result states “No retry policy set”.
How does “identity” get captured. I noticed that its different with in one workflow at different workflow tasks.
Identity is set through WorkflowClientOptions.identity. Its default value is the name of RuntimeMxBean. If a worker fails or workflow gets out of cache it can be loaded by a different worker instance. Thus you see different worker identities for the same workflow execution.
Does identity get used to restart the workflow? I mean if identity is not network, then reset will timeout?
Identity is purely for human consumption. It is not used anywhere by the workflow or server code.
Please point me to code repo for java sdk ResetWorkflowExecution ?
Hi
I am using local Activities and need to reset the workflow from failed state, is it supported in java sdk?
Also when I try to reset ,I could do it just once.
can’t we restart a workflow multiple times?
Ran into the same thing locally. Consecutive resets of the same workflow seem to reuse the same workflow execution that was created for the very first reset. Checking with server team to see if we should file an issue (bug).
Update. Can’t reproduce this consistently. Can you on your end?
Do you mean from a local activity in another workflow?
I don’t think local activities are best choice for this. They work only for short activities that do not exceed the workflow task timeout. ResetWorkflowExecutionRequest is client api and could take a long time to possibly complete.
This doesn’t work with the sequence of local activities as they are all executed as a single workflow task. The whole sequence is reexecuted in this case.
Why are you using workflow reset to deal with activity failures? I would recommend using normal activities and retrying them for a long time to deal with underlying failures. This way no manual intervention is needed once the failure is fixed.