-
Notifications
You must be signed in to change notification settings - Fork 216
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
Typed Search Attributes #1368
Typed Search Attributes #1368
Conversation
8fb7264
to
298a4a9
Compare
298a4a9
to
6679d9c
Compare
workflow/workflow.go
Outdated
// [Visibility]: https://docs.temporal.io/visibility | ||
func UpsertSearchAttributes(ctx Context, attributes map[string]interface{}) error { | ||
return internal.UpsertSearchAttributes(ctx, attributes) | ||
} | ||
|
||
// UpsertTypedSearchAttributes is used to add, update, or remove workflow search attributes. The search attributes can | ||
// be used in query of List/Scan/Count workflow APIs. The key and value type must be registered on temporal server side; | ||
// The value has to deterministic when replay; The value has to be Json serializable. |
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.
The value has to deterministic when replay
It does?
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 just took this doc from UpsertSearchAttributes
. But I just confirmed that we only check event type for upsert. So I will remove this statement from both Godocs on next commit (still going to wait for CLI publish to see if some CLI errors are solved).
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.
Updated
What happens if I mix and match upserting typed and untyped search attributes and what do the typed and untyped getters return ? |
SearchAttributeKeyKeywordList struct { | ||
baseSearchAttributeKey | ||
} | ||
) |
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 we do a SearchAttributeKeyRawPayload
? As I found while doing Omes stuff, being able to pass though payloads is very convenient in some cases. We can add a docstring to the effect of "this is for advanced use cases only"
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.
We can, though I'm not as big of a fan of us adding tools for ourselves only to save a switch
or similar. @Quinn-With-Two-Ns - thoughts? (also worth discussing whether it's this PR or another)
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 don't think it's only useful for us - it's useful when doing something like copying data from one workflow to another, or enabling things like the use case we were talking about where someone might scrape a workflow's history and apply things in it to the current workflow.
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.
That is a general problem with the inability to work with raw values in Go. The goal here was to not be able to provide the incorrect type even if you wanted to. But I don't mind the "raw" key if @Quinn-With-Two-Ns also agrees. Also open to other ideas that doesn't put it on par with all other properly-typed keys.
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.
Hm to copy from one workflow to another can't a user do SearchAttributes.Copy()
? If the only use is out Omes DSL I wouldn't add "raw" keys. If we did want it it should be in all languages not just Go, so maybe we should move the discussion out of this PR?
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.
Well they may not necessarily be other SAs is the problem. It could be input to the workflow, from a signal, etc, which you're accepting as a Payload
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.
@Sushisource can we open a features issue to discuss this? I think it's not included in Chads original proposal for TS attributes temporalio/proposals#75 and if we did do it I'd want it in all langs that make sense not just Go.
Can you clarify the scenario a bit better? Do you mean for something like workflow start? Or workflow use?
Untyped getter returns what it always had, no behavior change there. Typed returns only type-present search attributes which is supposed to be all of them. |
In a workflow someone calling a mix of the typed and untyped upsert
So if a user uses the typed API to upsert will the result not be present in the untyped getter? |
Each would result in independent commands. Untyped behaves as it always has, typed behaves as expected. I'm not sure we need to solve for advanced cases of mixing these in the same task.
I just copied your previous code which seems to delegate both to the environment's |
@@ -1221,6 +1221,15 @@ func (ts *IntegrationTestSuite) TestWorkflowWithParallelMutableSideEffects() { | |||
ts.NoError(ts.executeWorkflow("test-wf-parallel-mutable-side-effects", ts.workflows.WorkflowWithParallelMutableSideEffects, nil)) | |||
} | |||
|
|||
func (ts *IntegrationTestSuite) TestWorkflowTypedSearchAttributes() { |
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 we have a test that confirms TemporalChangeVersion
is set properly and accessible with typed search attributes?
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.
👍 Will add (next commit, was waiting for CLI to release dev server with temporalio/temporal#5124, but looks like that's not even released server side)
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.
Added test. I am setting the index value type to KeywordList
when converting to typed if not already set because I felt this was the safer route vs changing how the search attribute is set.
16d5d3b
to
8a917bc
Compare
What was changed
Implementation of typed search attributes. Specifically:
TypedSearchAttributes
toclient.StartWorkflowOptions
and deprecatedSearchAttributes
temporal
package including:SearchAttributes
collection with methods and constructorSearchAttributeKey
andSearchAttributeUpdate
interfacesSearchAttributeKeyX
types and constructors for typed keysTypedSearchAttributes
toclient.ScheduleWorkflowAction
and 💥removedSearchAttributes
and addedUntypedSearchAttributes
(needed until Eagerly validate and put proper metadata on search attributes for on schedule workflow action temporal#4787 is fixed)TypedSearchAttributes
toclient.ScheduleOptions
and deprecatedSearchAttributes
GetTypedSearchAttributes
toworkflow
and deprecatedWorkflowInfo.SearchAttributes
UpsertTypedSearchAttributes
toworkflow
and deprecatedUpsertSearchAttributes
Much of this work was done by @Quinn-With-Two-Ns
💥 BREAKING CHANGE
Users that used
SearchAttributes
onclient.ScheduleWorkflowAction
will now have a compile-time failure (not to be confused with search attributes on the schedule itself). There was no good way to have both untyped and typed coexist for create, describe, and update of a workflow action on a schedule. The release notes should document this break intentionally. This is the same decision we reached in Python.Checklist
NOTE: Currently there are two dev-server bugs (lack of
TemporalScheduledX
search attrs in workflow and a case where a SA name is appearing asText01
) that I'm hoping have since been fixed and are awaiting CLI release. That's why CI is failing, but can still review.