use UnsetVersioningOverride field in ApplyWorkflowExecutionOptionsUpdatedEvent #7091
+91
−34
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rodrigozhou
reviewed
Jan 16, 2025
…and override is nil in event
rodrigozhou
approved these changes
Jan 18, 2025
carlydf
added a commit
to temporalio/api
that referenced
this pull request
Jan 18, 2025
…Attributes (#516) _**READ BEFORE MERGING:** All PRs require approval by both Server AND SDK teams before merging! This is why the number of required approvals is "2" and not "1"--two reviewers from the same team is NOT sufficient. If your PR is not approved by someone in BOTH teams, it may be summarily reverted._ <!-- Describe what has changed in this PR --> ### What: Add unset_versioning_override to WorkflowExecutionOptionsUpdatedEventAttributes <!-- Tell your future self why have you made these changes --> ### Why: So that users of this event don't need to load VersioningOverride from mutable state every time they create this event. This change was prompted because the event is now being used for non-version-override-related things, and I received feedback that it is inefficient / awkward / error-prone to have to load and pass in the current versioning override every time anyone writes to this event. Now, a nil Versioning Override in this event means "no change" instead of "remove". This reduces the chance that someone accidentally unsets an override in the future, and also is more efficient. We've discussed this change internally in the server team and are ok with changing the meaning of this history event, because it is such a small change and the scope of impact is small (pre-release versioning users who have unset a versioning override and are building mutable state from that history). <!-- Are there any breaking changes on binary or code level? --> ### Breaking changes? Now, a nil Versioning Override in this event means "no change" instead of "remove". If an event exists with the previous meaning and the mutable state is rebuilt, the Versioning Override would not be removed. But the chance of that happening is very low. <!-- If this breaks the Server, please provide the Server PR to merge right after this PR was merged. --> temporalio/temporal#7091
temporal-cicd bot
pushed a commit
to temporalio/api-go
that referenced
this pull request
Jan 18, 2025
…Attributes (#516) _**READ BEFORE MERGING:** All PRs require approval by both Server AND SDK teams before merging! This is why the number of required approvals is "2" and not "1"--two reviewers from the same team is NOT sufficient. If your PR is not approved by someone in BOTH teams, it may be summarily reverted._ <!-- Describe what has changed in this PR --> ### What: Add unset_versioning_override to WorkflowExecutionOptionsUpdatedEventAttributes <!-- Tell your future self why have you made these changes --> ### Why: So that users of this event don't need to load VersioningOverride from mutable state every time they create this event. This change was prompted because the event is now being used for non-version-override-related things, and I received feedback that it is inefficient / awkward / error-prone to have to load and pass in the current versioning override every time anyone writes to this event. Now, a nil Versioning Override in this event means "no change" instead of "remove". This reduces the chance that someone accidentally unsets an override in the future, and also is more efficient. We've discussed this change internally in the server team and are ok with changing the meaning of this history event, because it is such a small change and the scope of impact is small (pre-release versioning users who have unset a versioning override and are building mutable state from that history). <!-- Are there any breaking changes on binary or code level? --> ### Breaking changes? Now, a nil Versioning Override in this event means "no change" instead of "remove". If an event exists with the previous meaning and the mutable state is rebuilt, the Versioning Override would not be removed. But the chance of that happening is very low. <!-- If this breaks the Server, please provide the Server PR to merge right after this PR was merged. --> temporalio/temporal#7091
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What changed?
use UnsetVersioningOverride field in ApplyWorkflowExecutionOptionsUpdatedEvent
Why?
So that users of this event don't need to load VersioningOverride from mutable state every time they create this event.
Now, a nil Versioning Override in this event means "no change" instead of "remove".
This reduces the chance that someone accidentally unsets an override in the future, and also is more efficient.
We've discussed this change internally in the server team and are ok with changing the meaning of this history event, because it is such a small change and the scope of impact is small (pre-release versioning users who have unset a versioning override and are building mutable state from that history).
How did you test it?
Made sure that versioning override functional tests pass.
Potential risks
Now, a nil Versioning Override in this event means "no change" instead of "remove".
If an event exists with the previous meaning and the mutable state is rebuilt, the Versioning Override would not be removed.
But the chance of that happening is very low.
Documentation
Is hotfix candidate?