I saw this thread for go sdk, but it wasn’t clear how this would be implemented with Java SDK. Replay a history in the debugger
Is there any videos, documentation or examples of this?
Thanks,
Derek
I saw this thread for go sdk, but it wasn’t clear how this would be implemented with Java SDK. Replay a history in the debugger
Is there any videos, documentation or examples of this?
Thanks,
Derek
There is no documentation. Here is a unit test that uses it.
Thanks. Just wanted to clarify is replay the process of retrieving the workflow execution history and then replaying it? When I look at the unit test, it looks like it’s assuming you are using the API to get the history and then putting it in a json to execute.
WorkflowReplayer.replayWorkflowExecutionFromResource(
"testAsyncActivityRetryHistory.json", TestAsyncActivityRetry.class);
I guess mentally I imagined that you would specify an already existing workflowID and replay would just take that ID and replay it. Is that the wrong way to think of it?
For example, in my case I want to take an already executed workflow and just execute it multiple of times creating a new runId for each one. For some reason I thought the startWorkflowExecution
was the way to do that, but I think that’s not it.
Currently, you need to manually download the workflow execution history.
This functionality exists to facilitate workflow logic update. When workflow logic is updated, generated history events can be different. This functionality let you apply existing workflow history to new workflow logic for verification.
Similar feature was mentioned multiple times for easier workflow forward / backward test.
I am not entirely sure I understand this, can you plz be more specific?
start workflow execution will tell service to send a task to your SDK executing a workflow function.
SDK, when executing the workflow can go offline, thus server need to pick another SDK to continue the execution. The another SDK will recreate the workflow state (and then continue execution) by download the to be continued workflow execution history and replay the events, then continue execution.
Hope ^ will help
Similar feature was mentioned multiple times for easier workflow forward / backward test.
Is there any plans to support the similar feature
@darewreck would you explain what you are trying to achieve from the use case point of view? Restarting workflows form the beginning or some middle point and replaying them are completely different features.
Hi @maxim
What i’m trying to do is just restart a workflow from the beginning? This would be different then replaying
a set of events in the history as you have pointed out which is useful for trouble shooting (if i’m understanding that correctly)
Thanks,
Derek
To restart workflow from the beginning you can start it again with the same arguments.
Another option is to reset workflow from the first WorkflowTaskStarted event.
Sure, we could pass the same arguments. But it would be nice if we could just pass the workflowID/RunId that executed and the system would be able to retrieve the initial inputs vs requiring the user to inject it.
I’ll look into the second option. Is there any implication with reseting
a workflow or downsides with doing this approach?
Currently, both approaches would require reading the beginning of the workflow event history. The former to get the workflow arguments, the letter to get the eventId
to reset to.
I added an issue to move the reset point calculation logic from tctl to the service.
I’m a bit confused on what you are trying to achieve here, but let me summarize your options:
WorkflowReplayer
for debugging if you want to replay history in the test.I’m imagining a scenario where it would useful to download a specific Workflow’s history for debugging purposes. I.e., examine what may have gone wrong on a particular run of a Workflow. Is it possible to download history, and then using WorkflowReplayer
, replay the Workflow with the debugger? If so, can you share how this is done?
Thanks in advance.
If you have WorkflowClient that connects to server instance where your execution ran could do
WorkflowReplayer.replayWorkflowExecution(
client.fetchHistory("<wfid>").toJson(true),
MyWokflowImpl.class);
(fetchHistory can take runid as second parameter)