Improve determinism explanation #3614
Conversation
| - Ending the Workflow Execution in any way (completing, failing, cancelling, or continuing as new) | ||
| - Patched or GetVersion calls for versioning (though they may be added or removed according to the [patching](#patching) rules) | ||
| - Upserting Workflow search attributes | ||
| - Upserting Workflow memos |
There was a problem hiding this comment.
nit: can include SideEffect and MutableSideEffect here too
|
|
||
| More formally, the use of certain Workflow APIs in the function is what generates | ||
| [Commands](/workflow-execution#command). Commands tell the Temporal Service which Events to create | ||
| and add to the Workflow Execution's [Event History](/workflow-execution/event#event-history). When a |
There was a problem hiding this comment.
I think the mention of "Workflow Function" here could be confusing, partly because of the formality implied by the uppercase F and partly because the term isn't consistent for all SDKs (such as Java, where the Workflow is defined in a method). Using "Workflow Definition" instead of "Workflow Function" would alleviate that, but that also sounds weird to me.
So, instead of this:
When a Workflow Function replays, the Commands that are emitted are compared
with the existing Event History.
Consider this:
When the Workflow's code replays, the Commands that are emitted are compared
with the existing Event History.
(Or alternatively, "When the Worker replays code in the Workflow Definition, the Commands ...")
There was a problem hiding this comment.
Yeah, I agree. I was trying to get rid of some of these old overly formal terms we insisted on having in the past but I didn't know what the feeling was on that now. Happy to do something simpler.
Sushisource
force-pushed
the
improve-determinism
branch
from
ca53a22 to
67658fd
Compare
What does this PR do?
Provide the answers people are looking for up front in simpler language before diving into details.
Notes to reviewers