NEXUS-484: Support UpdateWorkflow as a Nexus Operation by mavemuri · Pull Request #1631 · temporalio/sdk-python

mavemuri · 2026-07-02T04:02:16Z

What was changed

Adds support for UpdateWorkflow as a Nexus operation

Why?

Part of effort to expose all Temporal primitives via Nexus operations

Checklist

Closes
NEXUS-484
How was this tested:

added integration test

Any docs updates needed?

CLAassistant · 2026-07-02T04:02:23Z

All committers have signed the CLA.

mavemuri · 2026-07-02T20:02:00Z

+        result = await wf_handle.result()
+        assert result == "Updated workflow status from Pending to Created"
+
+        # await assert_event_subsequence(


TODO:

~~- [ ] check why this is flaky on ubuntu-arm/windows~~

verify links are present

check resp is sync on the retried update below

Probably obvious, but just to note we should try to match the test coverage we have in Go

Quinn-With-Two-Ns · 2026-07-15T21:24:04Z

+        result_type: type | None = None,
+        rpc_metadata: Mapping[str, str | bytes] = {},
+        rpc_timeout: timedelta | None = None,
+        # run_id: str | None = None,


Why are these commented out

wasnt sure if they were required at the time, fixed it

Quinn-With-Two-Ns · 2026-07-15T21:24:55Z



+@dataclass(frozen=True)
+class CancelUpdateWorkflowOptions:


Missing run ID

VegetarianOrc · 2026-07-16T20:31:05Z

+        if run_id == None:
+            run_id = self._run_id
+        if first_execution_run_id == None:
+            first_execution_run_id = self.first_execution_run_id
+


If we decide to keep this, let's make sure to use is None

Suggested change

if run_id == None:

run_id = self._run_id

if first_execution_run_id == None:

first_execution_run_id = self.first_execution_run_id

if run_id is None:

run_id = self._run_id

if first_execution_run_id is None:

first_execution_run_id = self.first_execution_run_id

VegetarianOrc · 2026-07-16T20:43:20Z


    return WorkflowHandle[ReturnType]._unsafe_from_client_workflow_handle(wf_handle)
+
+
+async def _start_nexus_backed_workflow_update(  # pyright: ignore[reportUnusedFunction]
+    *,
+    temporal_context: _TemporalStartOperationContext,
+    workflow_id: str,
+    update: str | Callable,
+    arg: Any = temporalio.common._arg_unset,
+    args: Sequence[Any] = [],
+    id: str | None = None,
+    result_type: type | None = None,
+    rpc_metadata: Mapping[str, str | bytes] = {},
+    rpc_timeout: timedelta | None = None,
+    run_id: str | None = None,
+    first_execution_run_id: str | None = None,


Instead of getting the workflow handle with just workflow_id and then passing run_id and first_execution_run_id to handle._start_update we should get the handle with those IDs.

workflow_handle = temporal_context.client.get_workflow_handle( workflow_id, run_id=run_id, first_execution_run_id=first_execution_run_id, )

Then in the details of workflow_handle._start_update we can remove the new run_id and first_execution_run_id args and the checks for if they're set or not.

Missed this - will fix!

VegetarianOrc · 2026-07-16T20:45:45Z

+        run_id: str | None = None,
+        first_execution_run_id: str | None = None,


These fields must be present on the various overloads as well.

VegetarianOrc · 2026-07-16T20:47:15Z

+        arg: Any = temporalio.common._arg_unset,
+        *,
+        args: Sequence[Any] = [],
+        id: str | None = None,


IMO we should consider naming this update_id to more clearly differentiate between workflow_id and the other IDs necessary.

The current code seems to be using "id" as the defacto operation-relevant unique ID - eg. start_workflow uses "id" for workflowID - this is the case for the primitive start_update/etc as well -

sdk-python/temporalio/client/_workflow.py

Line 923 in c6386e9

id: ID of the update. If not set, the default is a new UUID.

Was trying to follow that but explicit does make sense. It might look inconsistent if update calls out specific and start_workflow doesnt- because that part is already solidified/shipped iiuc

I agree with changing it update_id - because update has both workflow_id and update_id - but just not sure because of this

VegetarianOrc · 2026-07-16T20:48:05Z

+    # draft-review: check why run_id and first_execution_run_id are not used
+    # for update workflow in python sdk


These are sourced from the WorkflowHandle rather than passed as arguments.

VegetarianOrc · 2026-07-16T20:52:42Z

+                first_execution_run_id=first_execution_run_id,
+            )
+            # If the update has already completed, return the result synchronously
+            # This is in-line with the Go implementation as well


Suggested change

# This is in-line with the Go implementation as well

VegetarianOrc · 2026-07-16T20:53:36Z

+        run_id: str | None = None,
+        first_execution_run_id: str | None = None,


As mentioned in other comments, I think we should remove these and always use self._run_id and self._first_execution_run_id

VegetarianOrc · 2026-07-16T20:58:36Z

+        nexus_handle: UpdateHandle[Any] = (
+            UpdateHandle._unsafe_from_client_workflow_update_handle(update_handle)
+        )


I know the workflow variant uses a WorkflowHandle here, but I'm not sure it's necessary. I think we should remove the UpdateHandle and just contruct the appropriate OperationToken here.

Makes sense- will just re-generate from the handle there

VegetarianOrc · 2026-07-16T21:01:39Z

+    # draft-review: maybe just move it inline, no need for a function just to error out
+    # check after review in case theres some other way to override/supply custom cancels


The way to customize cancellation is to inherit from TemporalOperationHandler and override these methods. So we'll either need to rework how that's done or leave these methods in place.

mavemuri force-pushed the mavemuri/update-nexus-op branch 6 times, most recently from a913bdd to 79d24c1 Compare July 2, 2026 18:52

mavemuri commented Jul 2, 2026

View reviewed changes

mavemuri force-pushed the mavemuri/update-nexus-op branch 2 times, most recently from ecc3c9e to e38becf Compare July 13, 2026 20:00

Quinn-With-Two-Ns reviewed Jul 15, 2026

View reviewed changes

mavemuri force-pushed the mavemuri/update-nexus-op branch 6 times, most recently from d8db6d8 to 351568c Compare July 16, 2026 20:03

VegetarianOrc reviewed Jul 16, 2026

View reviewed changes

mavemuri force-pushed the mavemuri/update-nexus-op branch 4 times, most recently from 82de56f to 407a188 Compare July 17, 2026 02:46

NEXUS-484: Add support for workflow update Nexus operations

02aab62

mavemuri force-pushed the mavemuri/update-nexus-op branch 3 times, most recently from 6ea104d to 83ed716 Compare July 17, 2026 05:07

address comments, cleanup run_id, extend tests

a750f5f

mavemuri force-pushed the mavemuri/update-nexus-op branch from 83ed716 to a750f5f Compare July 17, 2026 05:24

		run_id: str \| None = None,
		first_execution_run_id: str \| None = None,

		# draft-review: check why run_id and first_execution_run_id are not used
		# for update workflow in python sdk

		# draft-review: maybe just move it inline, no need for a function just to error out
		# check after review in case theres some other way to override/supply custom cancels



		@dataclass(frozen=True)
		class CancelUpdateWorkflowOptions:

Uh oh!

Conversation

mavemuri commented Jul 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What was changed

Why?

Checklist

Uh oh!

CLAassistant commented Jul 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mavemuri Jul 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mavemuri Jul 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

mavemuri commented Jul 2, 2026 •

edited

Loading

CLAassistant commented Jul 2, 2026 •

edited

Loading

mavemuri Jul 2, 2026 •

edited

Loading

mavemuri Jul 16, 2026 •

edited

Loading