Nexus samples #174
Nexus samples #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.
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.
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)
There was a problem hiding this comment.
Thanks. The current design is it returns nexus.WorkflowHandle. I've confirmed that a type-safe fetch_result implementation is impossible, via run-time access to the generic type params.
hello_nexus/basic/handler/worker.py
Outdated
| 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.
This is a bit hard to follow for a sample, can they just be different services that are both registered?
There was a problem hiding this comment.
I've removed the class-based operation from the sample for now.
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.
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).
|
Semgrep found 1 Risk: Affected versions of protobuf are vulnerable to Uncontrolled Recursion. The pure-Python implementation of Protocol Buffers is vulnerable to a denial-of-service attack when processing untrusted data with deeply nested or recursive groups/messages, potentially causing the Python recursion limit to be exceeded. Manual Review Advice: A vulnerability from this advisory is reachable if you have setup pure-Python backend through compiler and using it throug Command Line Interface. Fix: Upgrade this library to at least version 5.29.5 at samples-python/uv.lock:1982. Reference(s): GHSA-8qvm-5x2c-j2w7, CVE-2025-4565 |
Rendered: https://github.com/temporalio/samples-python/tree/nexus/hello_nexus