-
Notifications
You must be signed in to change notification settings - Fork 163
Set TemporalChangeVersion when workflow version is updated #2464
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Set TemporalChangeVersion when workflow version is updated #2464
Conversation
e7ec581
to
e77c71c
Compare
details.put( | ||
UPSERT_VERSION_SA_KEY, | ||
DefaultDataConverter.STANDARD_INSTANCE.toPayloads(upsertVersionSA).get()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you help me understand the changing of the marker value here. Do other SDKs do this and/or are we using it as a flag of sorts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes Go does the same thing, it tells the SDK if it should expect a search attribute after the marker.
@@ -508,6 +534,14 @@ private void handleCommandEvent(HistoryEvent event) { | |||
if (handleLocalActivityMarker(event)) { | |||
return; | |||
} | |||
if (shouldSkipUpsertVersionSA) { | |||
if (handleNonMatchingUpsertSearchAttribute(event)) { | |||
shouldSkipUpsertVersionSA = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this bool only valid for this one event? Does setting it back to false here make a difference, or is it just to be safe?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes it is only valid for one event
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I admit I didn't do a deep dive, but the test coverage does provide some comfort here couple with the fact that it's not even enabled by default today. May be worth getting review from others if needing multiple opinions/eyes.
* with running workflows. However, if this options is enabled, it is not safe to rollback to a | ||
* previous version of the SDK that does not support this option. | ||
* | ||
* <p>The default value is false. This may change in future releases. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wonder if we need an issue to track enabling this by default after a release or two
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this does indeed match Core
temporal-sdk/src/main/java/io/temporal/internal/replay/ReplayWorkflowContextImpl.java
Outdated
Show resolved
Hide resolved
8b49685
to
3bd0dd6
Compare
3bd0dd6
to
35d1dc8
Compare
Set TemporalChangeVersion when workflow version is updated
This PR adds an option to
WorkflowImplementationOptions
that if set to true will causeGetVersion
to automatically upsertTemporalChangeVersion
with a list of version. The reason why this is behind a flag is to allow for safe rollback and to help users who are already manually upserting a search attribute migrate.Note for reviewers: I still need to fix the parametrized test to cover both the flag being enabled and disable, and add more replay tests, but all the tests I intended to add are here otherwise. I welcome suggestions for more test coverage
closes #587