-
Notifications
You must be signed in to change notification settings - Fork 220
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
Experimental user metadata and workflow metadata query support #1597
Conversation
@@ -231,6 +231,9 @@ type WorkflowOutboundInterceptor interface { | |||
// NewTimer intercepts workflow.NewTimer. | |||
NewTimer(ctx Context, d time.Duration) Future | |||
|
|||
// NewTimer intercepts workflow.NewTimerWithOptions. | |||
NewTimerWithOptions(ctx Context, d time.Duration, options TimerOptions) Future |
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.
Based on available options, a new outbound method seemed like the best approach here. Should be safe since we require the base to be embedded.
if options.Summary != "" { | ||
var err error | ||
if summary, err = dc.ToPayload(options.Summary); err != nil { | ||
panic(err) |
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.
This should be rare (it's just serializing string), but there is precedent with other commandsHelper
calls panicking if they can't convert.
@@ -45,7 +45,7 @@ type ( | |||
|
|||
// NewTimer - Creates a new timer that will fire callback after d(resolution is in seconds). | |||
// The callback indicates the error(TimerCanceledError) if the timer is canceled. | |||
NewTimer(d time.Duration, callback ResultHandler) *TimerID | |||
NewTimer(d time.Duration, options TimerOptions, callback ResultHandler) *TimerID |
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.
This may break PHP SDK since it's exposed via internalbindings
but unsure if they use it. This seemed like the best way and should cause a clear compile break.
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 think they do but it should be fine
@@ -231,6 +231,9 @@ type WorkflowOutboundInterceptor interface { | |||
// NewTimer intercepts workflow.NewTimer. | |||
NewTimer(ctx Context, d time.Duration) Future | |||
|
|||
// NewTimer intercepts workflow.NewTimerWithOptions. |
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 other primitives support metadata like activities? Do we plan to add support for them?
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 and yes! We intentionally decided that workflow summary/details and timer summary was the first use case. But the user metadata is on the command/event and not the attributes for this reason. Any UI/CLI-visible metadata you could ever need on an event we can look into adding.
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 thought we had the ability to add this to child workflows straight away too?
@@ -45,7 +45,7 @@ type ( | |||
|
|||
// NewTimer - Creates a new timer that will fire callback after d(resolution is in seconds). | |||
// The callback indicates the error(TimerCanceledError) if the timer is canceled. | |||
NewTimer(d time.Duration, callback ResultHandler) *TimerID | |||
NewTimer(d time.Duration, options TimerOptions, callback ResultHandler) *TimerID |
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 think they do but it should be fine
internal/schedule_client.go
Outdated
@@ -281,6 +281,23 @@ type ( | |||
// | |||
// Deprecated - This is only for update of older search attributes. This may be removed in a future version. | |||
UntypedSearchAttributes map[string]*commonpb.Payload | |||
|
|||
// Summary - Single-line summary for this workflow execution that will appear in UI/CLI. This can be in | |||
// single-line Temporal markdown format. |
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.
None of these strings that reference this markdown format have info about what it is. Probably because it doesn't exist yet, but, if it does somewhere, link would be good.
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.
Yeah, as this concept is stabilized (i.e. non-experimental) and we have something at docs.temporal.io, would definitely want to link it here.
Yes, will add |
Actually I am not seeing child workflow as working. I put in a bunch of work to wire it up for child workflows then my integration tests show it didn't propagate. I will get with authors of temporalio/temporal#5857, but in the meantime I will add everything but the final user-facing option. |
# Conflicts: # .github/workflows/ci.yml # test/workflow_test.go
Updated to change to |
if err != nil { | ||
return nil, err | ||
} | ||
|
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 need a similar change when the schedule is updated. The UpdateSchedule
API on the server is structured to completely replace the schedule.Action
with the value provided in the update API. So if the client wants to update a single field, it should echo back the whole schedule with the updated field. The client already seems to be doing that.
But in my testing I noticed that the usermetadata is not being copied over between these two calls - https://github.com/temporalio/sdk-go/blob/master/internal/internal_schedule_client.go#L276-L280. Looks like ScheduleWorkflowAction
struct needs some updates?
cc @dnr
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.
This same code is used for update. The way update works in SDKs is it's a get-then-update which calls these same helpers to go from user model to proto model.
What was changed
StartWorkflowOptions.StaticSummary
andStartWorkflowOptions.StaticDetails
fields that are populated on workflow start event and execution configworkflow.SetCurrentDetails
andworkflow.GetCurrentDetails
functions that set current details available on workflow metadata queryworkflow.NewTimerWithOptions
that accepts aTimerOptions
which has aSummary
to be put on the timer eventworkflow.SetQueryHandlerWithOptions
that accepts aQueryHandlerOptions
which has aDescription
workflow.GetSignalChannelWithOptions
that accepts aSignalChannelOptions
which has aDescription
__temporal_workflow_metadata
query that returns query, signal, and update definitions and the current detailsNote, some things are not supported:
Checklist