-
Notifications
You must be signed in to change notification settings - Fork 66
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
Add SDK-only workflow metadata #336
Add SDK-only workflow metadata #336
Conversation
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.
Looks great! Only pedantic stuff about comments. Would like to wait on rest of team to review too.
@@ -2,3 +2,4 @@ | |||
/.gen | |||
/.vscode | |||
/.stamp | |||
*~ |
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.
What commonly created files does this ignore?
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'm using emacs, best editor in the world
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 it the best editor in the world if you have to update your gitignore to avoid it's leftovers? 😁 Anyways, all good, just wanted to confirm our tooling wasn't leaving things around
// If missing, it represents a dynamic workflow invoked when the requested | ||
// type does not match any other registered workflow type. | ||
// There is at most one dynamic workflow per task queue. |
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.
// If missing, it represents a dynamic workflow invoked when the requested | |
// type does not match any other registered workflow type. | |
// There is at most one dynamic workflow per task queue. | |
// If missing, this workflow is a dynamic workflow. |
Don't need the other parts of the comment, that applied to when "worker queries" were a thing.
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.
OK. I guess it should be well known what a dynamic workflow is by now...
// By convention, external tools may interpret its first sentence, | ||
// i.e., ending with a "." followed by a line break, as a summary of the description. |
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.
// By convention, external tools may interpret its first sentence, | |
// i.e., ending with a "." followed by a line break, as a summary of the description. | |
// By convention, external tools may interpret its first part, | |
// i.e., ending with a line break, as a summary of the description. |
My fear is that we are not going to enforce that the sentence boundary is also the line-break boundary, so how would the UI team write code to parse this? Similarly there may not be a line break at all if it's summary only. I think just "first line is summary" is acceptable, and UI can of course add an ellipsis or similar if even that is too long.
Or if you want to make sentence + line break a thing, do as https://pkg.go.dev/go/doc#Package.Synopsis does and say
// By convention, external tools may interpret its first sentence, | |
// i.e., ending with a "." followed by a line break, as a summary of the description. | |
// By convention, external tools may interpret its first sentence, | |
// i.e., ending with a "." followed by space and not preceded by capital letter or at first paragraph break, as a summary of the description. |
(same goes for interaction definition)
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.
Alternatively, it could just be markdown.
But, I think just text that the UI can decide to cut off wherever is totally fine too.
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.
Would like to keep it plain text for now instead of markdown (that becomes a mess for UI people). But if we expect descriptions to have summaries that are cutoff at a specific point it's worth saying what that recommended cutoff is for both UI and description-writer benefit.
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.
OK, let's keep it simple with "first line is summary". If the UI folks want other convention, it is just a comment change.
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 problem here is that newlines are hard/ugly in metadata string literals in lots of programming languages. Imagine a Java annotation with newlines. I do kinda like the "line break or first non-acronym dot followed by space", but I have no strong opinion here.
repeated InteractionDefinition signal_definitions = 4; | ||
repeated InteractionDefinition update_definitions = 5; | ||
} | ||
// (-- api-linter: core::0123::resource-annotation=disabled |
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.
// (-- api-linter: core::0123::resource-annotation=disabled | |
// (-- api-linter: core::0123::resource-annotation=disabled |
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.
thanks
// aip.dev/not-precedent: The `name` field is optional. --) | ||
// (-- api-linter: core::0203::optional=disabled --) | ||
message InteractionDefinition { | ||
// An optional name to select the handler. If missing, it represents |
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.
// An optional name to select the handler. If missing, it represents | |
// An optional name for the handler. If missing, it represents |
There is no real selecting here
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.
Done
// (-- api-linter: core::0203::optional=disabled --) | ||
message InteractionDefinition { | ||
// An optional name to select the handler. If missing, it represents | ||
// a dynamic handler that process any interactions not handled by others. |
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.
// a dynamic handler that process any interactions not handled by others. | |
// a dynamic handler that processes any interactions not handled by others. |
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.
Thanks
option ruby_package = "Temporalio::Api::Sdk::V1"; | ||
option csharp_namespace = "Temporalio.Api.Sdk.V1"; | ||
|
||
message WorkflowMetadata { |
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 add a comment saying the name of the query that retrieves this information? We need that somewhere, we might as well put it here.
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.
Makes sense, using __temporal_getWorkflowMetadata
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 benefit of that query is that it will fail on older SDKs thereby returning the same thing as the UI's little intentional-failed-query-check would. We do need to discuss the cloud pricing that may be associated with this query however (previously the intentional-failed-query-check would not charge because the query did not succeed).
// (-- api-linter: core::0123::resource-annotation=disabled | ||
// aip.dev/not-precedent: The `name` field is optional. --) | ||
// (-- api-linter: core::0203::optional=disabled --) | ||
message InteractionDefinition { |
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.
message InteractionDefinition { | |
message WorkflowInteractionDefinition { |
I should have qualified this when I first made this message, sorry. I would also support just Interaction
as a sub-message of WorkflowDefinition
.
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.
Using WorkflowInteractionDefinition
Will the query for this metadata have any parameters or are users only able to query for the full thing? |
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.
Cool! Agree with the doc suggestions
|
What changed?
Adding a message for workflow metadata that is only available in the SDK.
Why?
The goal is to provide a standard interface for all the SDKs to read workflow metadata such as registered query, signal or update handlers.
See #temporalio/features#51
Breaking changes
no