Workflow re-logs messages after being signaled

Temporal SDK version 1.11.0

Some relevant sample code from my workflow:

public class MyWorkflowImpl extends AbstractBaseWorkflowImpl implements MyWorkflow {
  Logger logger = Workflow.getLogger(MyWorkflowImpl.class);
  public MyType execute(Input input) {"Execution starting...");

AbstractBaseWorkflowImpl has a @SignalMethod updateStatus defined, and MyWorkflowImpl will wait at some point until updateStatus is called. The signal method can be called multiple times with different input.

I’m calling the signal method from a different workflow:

// This finds the correct workflow
String idToSignal = WorkflowUtility.determineWorkflowId(...);
ExternalWorkflowStub abstractBaseWorkflowStub = Workflow.newUntypedExternalWorkflowStub(idToSignal);
try {
  abstractBaseWorkflowStub.signal("updateStatus", "hello");
} catch (....)

When I run my integration tests using either TestWorkflowEnvironment or a Temporalite cluster, I see odd logging behavior. I signal MyWorkflowImpl twice, and see Execution starting... logged a total of 3 times. After following the logs, it looks like whenever updateStatus is called, Execution starting... and many other log messages get written again. So, the 3 times it is logged are from the workflow starting + 2x signals.

Activities do not get re-run, so the functional behavior is correct. However, the logs are quite confusing. Is there a way to stop the logs from being re-printed? I thought using Workflow.getLogger would avoid this.


You are right, using Workflow.getLogger would prevent the log to be re-printed if the workflow is replayed.

I have tried to reproduce the issue (using SDK Java version 1.11.0), and I have not been able to do it.

Would you be able to provide the history of the workflow (from your test) in JSON format?

you can get it with:

System.out.println(new WorkflowExecutionHistory(

Embarrassingly, I have not been able to reproduce this the last few days. If it happens again, I’ll be sure to grab the workflow history and add it here. Sorry!

No problem @nathan_shields!!