-
Notifications
You must be signed in to change notification settings - Fork 73
Nexus sample #174
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
base: main
Are you sure you want to change the base?
Nexus sample #174
Conversation
5f3def5
to
0448a6b
Compare
de436b0
to
8f7614c
Compare
57363e8
to
4f56301
Compare
from temporalio import workflow | ||
from temporalio.workflow import NexusClient | ||
|
||
from hello_nexus.basic.service import MyInput, MyNexusService, MyOutput |
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 should encourage passing through all contract/reference types like these that are known to be used deterministically (we encourage the same for activities and such).
@temporalio.nexus.handler.workflow_run_operation_handler | ||
async def my_workflow_run_operation( | ||
self, ctx: StartOperationContext, input: MyInput | ||
) -> WorkflowHandle[WorkflowStartedByNexusOperation, MyOutput]: |
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.
In other SDKs, there was a concern returning the actual started workflow handle, and instead they made a type specifically not to represent a "template" of what to start. IIRC, in addition to some other thinking around limiting control over when the actual start call was made, the thinking was that if they actually want to control the workflow start invocation, they could use a more generic "Temporal client-based" operation handler and that this one would provide no value.
See return type of https://pkg.go.dev/go.temporal.io/[email protected]/temporalnexus#NewWorkflowRunOperation, workflow method factory in https://www.javadoc.io/static/io.temporal/temporal-sdk/1.29.0/io/temporal/nexus/WorkflowRunOperation.html, etc.
There needs to be a way to know what workflow is being referenced for an operation without starting it. For instance, what does the implementation for fetch result for this workflow run operation look like? (even though that's not completely supported by Temporal yet, it is an important thought exercise)
MyNexusServiceHandlerUsingOperationHandlerClasses( | ||
connected_db_client=connected_db_client | ||
) | ||
if use_operation_handler_classes | ||
else MyNexusServiceHandler(connected_db_client=connected_db_client) |
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 is a bit hard to follow for a sample, can they just be different services that are both registered?
hello_nexus/basic/README.md
Outdated
--name my-nexus-endpoint \ | ||
--target-namespace my-target-namespace \ | ||
--target-task-queue my-target-task-queue \ | ||
--description-file ./hello_nexus/basic/service_description.md |
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 this is more endpoint description than service description. Even though this just happens to be a single-service endpoint currently, we might as well make it clear with filename and such (even just description.md
would work, though prefer endpoint_description.md
).
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
This reverts commit 6789490.
Rendered: https://github.com/temporalio/samples-python/tree/nexus/hello_nexus