-
Notifications
You must be signed in to change notification settings - Fork 15
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
[Feature Request] Standardize method for listing workflow queries/signals (and maybe other things like registered activities/workflows and other metadata) #51
Comments
There are other things that are only registered at the SDK level, e.g. signal handlers. I wonder if we want a more generic "get SDK workflow details" query that also shows signal handlers and potentially any other SDK-side-only metadata. Whatever is decided, of course it needs to be well specified since all SDKs need to support it in the exact same way. |
That's a good suggestion @cretz, let's do that. |
We should define the message in the API proto repo |
is it possible in theory to also provide input data type definitions? for both Queries and Signals in case we want to dynamically construct the UI |
@feedmeapples - Can discuss in separate issue/discussion as that's much more complex (and due to signals persisting in history even on bad input poses some issues alleviated by the upcoming synchronous update feature). |
Implementation ThoughtsThis should be represented as proto which every language and the UI can use. Granted the format will be JSON-based proto Here would be my idea (expressed in TS terms, but applicable to all SDKs): // This can be per workflow run or per workflow type
message WorkflowMetadata {
WorkflowDefinition definition = 1;
// TODO(cretz): Future possibilities
// * Stack information
// * Worker metadata sans workflow list
}
message WorkflowDefinition {
// If empty, this is a "dynamic" form of the workflow
string type = 1;
// Optional
string description = 2;
// When fetching at a worker level these are obviously fixed to the workflow
// definition which means that languages like Go need to provide a way to
// allow developers to define these things ahead of time if they want (unlike
// today which is runtime). When fetching at a workflow level, these may be
// specific to a run since handlers can be added inside of workflows.
//
// We can break these out to separate message types for each definition type
// if/when there are fields specific to each.
repeated InteractionDefinition signal_definitions = 3;
repeated InteractionDefinition query_definitions = 4;
repeated InteractionDefinition update_definitions = 5;
}
message InteractionDefinition {
// If empty, this is a "dynamic" form of the interaction
string name = 1;
// Optional. While we can support type hinting information for callers in
// more well-typed fields in the future, it gets complicated quickly.
// Therefore, all information a caller may need should currently be in English
// in this field (even if it's generated by the SDK).
string description = 2;
}
message ActivityDefinition {
// If empty, this is a "dynamic" form of the activity
string type = 1;
// Optional
string description = 2;
}
message WorkerMetadata {
repeated WorkflowDefinition workflow_definitions = 1;
repeated ActivityDefinition activity_definitions = 2;
// TODO(cretz): There are so many options here to add things such as:
// * Registration/config options
// * Cache info
// * Identity information we usually have for workers
// * SDK language and version
// * General process/metric info (but don't overdo this)
} Here are the calls one can make:
For discussion:
|
I would love to get this |
@cretz I wonder if we need to report dynamic workflow/interactions at all. In particular, if they don't have a description either, there is no proper way to identify them... |
This is about providing information to the caller about the shape of what is defined on the workflow. The caller may want to know that any query could be accepted because dynamic query is enabled. This can affect things like the UI where they may make it clear to a user that any arbitrary string query name would be accepted if they knew that dynamic queries were supported. Btw, if you are tackling this now, I would ignore anything about "worker queries" in this issue, that can be done somewhere else. |
|
This issue is known and #201 exists to bring parity here. Signals in Go for this feature request are going to be a bit interesting. My suggestion: there is no such thing as a signal definition in Go so we should never populate that repeated field in metadata. However, we can create helper API in Go like We're going to need to design how to provide "descriptions" to these interactions in every language anyways. In Go, I can provide clarification here if unclear. |
This needs to be done in every SDK other than TypeScript |
Note from UI sync: Good idea to have an "is visible in UI" flag for interactions Other possible future options:
|
Up until now we've used a hack to get the list of registered queries from a workflow execution.
The hack is to send a query to a workflow, which responds with something like "query not found, list of registered queries...", parse the response and show in the UI.
A standard way to support listing workflow queries would be to have a "listQueries" (name TBD) built-in query provided by the Workflow runtime.
We'd have to keep the hack around to support SDKs that still do not support the listQueries built-in query (all at the time of this writing).
UPDATE: Here is the roadmap:
The text was updated successfully, but these errors were encountered: