Hi
The Java sdk section on workflow id reuse policy doesn’t mention “terminate if running” at all, and the section in the encyclopaedia is misleading
This policy allows for only one Workflow Execution with a specific Workflow Id to be running at any given time.
This makes it sound like temporal offers a guarantee that the old workflow will stop before the new workflow starts - which would be quite useful for serialising access to objects to eliminate the possibility of race conditions. However in my experience when a workflow is terminated, it’s in-flight activities may continue running at the same time as the new workflow. There’s no guarantee which workflow’s activities will complete first, and it’s quite possible they will interfere with each other. Given that activities are where side effects occur, to me, this means the two workflows are running at the same time.
I’m not really sure what the purpose of this feature is and I think ideally it would wait for the activities to complete before starting the new workflow, however at the least the docs should be corrected
I’m fairly sure I read in the temporal docs that this feature could be used to serialise access to entities, but I can’t find it now. If it did exist, that place should be updated too
The Java sdk section on workflow id reuse policy doesn’t mention “terminate if running” at all,
Good catch, will report to docs team to add.
the section in the encyclopaedia is misleading
Workflow executions life cycle is managed by Temporal service. Terminate operations is like a “kill -9”, meaning service would terminate execution, without your workers being notified of this termination.
So what you observe with activities for terminated execution could still be running on your worker when execution is terminated by service is correct, and is the nature of terminate operation itself. These activities would at that point basically be canceled as service would reject their response/failure, and they would get learn about execution being terminated if they try to heartbeat.
TerminateIfRunning, does atomically (so in same transaction) terminate the currently running execution, and create a new one with same workflow id, so from that perspective the docs are imo correct.
I’m not really sure what the purpose of this feature is
Similarly to using terminate api itself, its imo just for cases where you just need to terminate the running execution, without regards to any pending activities, given that they might be idempotent or heartbeat so can deal with cancelation.