Is there an example of how you would replay a workflow in Java

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?


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.

        "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)


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:

  • Use continue as new feature in the workflow if you want to start next run from the workflow itself. You can pass a new set of input arguments to the new run.
  • Use start workflow if you want some control code to wait for the current run in order to finish and initiate a new run with same OR different arguments.
  • Use reset if you want to restart a workflow with the same arguments. This approach lets you reset to any workflow task in the middle and workflow doesn’t have to go from the start again.
  • Use WorkflowReplayer for debugging if you want to replay history in the test.