NEXUS-485: Support Workflow Update as a Nexus Operation by mavemuri · Pull Request #2945 · temporalio/sdk-java

mavemuri · 2026-07-10T03:07:20Z

What was changed

Adds support for Workflow Update as a Nexus operation

Why?

Part of effort to expose all Temporal primitives via Nexus operations

Checklist

Closes NEXUS-485
How was this tested:

added integration tests

Any docs updates needed?

TBD

Evanthx · 2026-07-10T18:51:22Z

+              .setWorkflowId(workflowID)
+              .setRunId(runID));
+    } catch (Exception e) {
+      log.error("Failed to parse Nexus link URL", e);


Might still want to log the bad URL, like you did above

Same as before, might have gotten unfixed!

Quinn-With-Two-Ns · 2026-07-14T16:01:32Z

+    // only run this test if the server supports update completion callbacks
+    // currently only for local server manual checks until the in-memory test
+    // server can support update completion callbacks
+    assumeTrue(


We should just skip the Update tests for the in-memory test server we should always be running these tests when using a real server for test. You can look at how we tested other things like Stand Alone Activities

So we won't need UPDATE_CALLBACKS_SUPPORTED

SDKTestWorkflowRule.useExternalService this wasnt enough as the test also needs update callbacks to be enabled via dynamic config
Didnt want to rely on just local server flag because someone could run server without those flags - they arent required anyway
Added this way to ensure that if someone runs this against their own server- for testing other SDK changes etc- itll only get tested iff the server supports it
Or can add a note if someone runs into this that theyd need to enable flags on their real server

Yes you should assume the users server has this DC set or fail the test

To run SDK test against a local server you have to set the require DC, that is true is all SDKs CI

Got it - will change and just add a comment

Quinn-With-Two-Ns · 2026-07-14T16:03:21Z

+                    requestLinks))
+            .addAllLinks(requestLinks);
+      } else {
+        log.error("unexpected error fetching nexusOperationMetadata");


This is an expected case if the user makes a regular update call from the regular Temporal client inside a Nexus handler, we need to make sure that still works like before and we didn't break anything there

Quinn-With-Two-Ns · 2026-07-15T20:51:14Z

+  @Override
+  public <T, A1, A2, A3, A4> TemporalOperationResult<Void> startWorkflowUpdate(
+      Class<T> workflowClass,
+      String workflowId,


I think we need overloads that take the workflow execution as well to target the specific run ID , @maciejdudko thoughts?

added one just to align on the shape here https://github.com/temporalio/sdk-java/pull/2945/changes#diff-5f53049561675309c6d8a1a6b09638b2e6e9096a5b614047e2d96d4491ed5a73R776

Just so we're on the same page, if we want to do this, there will be 15 more(additional, not replacement) that will have workflow execution instead of the workflowID right?

Yeah it is a lot of overloads , but we need to be able to target by workflow ID or (Workflow ID, Run ID) pair

Quinn-With-Two-Ns · 2026-07-15T20:52:00Z

+  private <R> void checkNexusUpdateOptionsValid(UpdateOptions<R> options)
+      throws OperationException {
+    if (options.getWaitForStage() != WorkflowUpdateStage.ACCEPTED) {
+      throw OperationException.failed(


I don't think this should fail the Nexus operation, I thought we already decided that in the Go SDK PR

updated to handler error to retry

Quinn-With-Two-Ns · 2026-07-15T21:22:43Z

+
+  public CancelUpdateWorkflowInput(String workflowId, String runId, String updateId) {
+    this.workflowId = Objects.requireNonNull(workflowId);
+    this.runId = Strings.nullToEmpty(runId);


Note still need to update this to require

Evanthx · 2026-07-21T22:32:46Z

+              .setWorkflowId(workflowID)
+              .setRunId(runID));
+    } catch (Exception e) {
+      log.error("Failed to parse Nexus link URL", e);


Same as before, might have gotten unfixed!

mavemuri · 2026-07-22T16:40:14Z

Might have gotten unfixed. :-D It's still BAD_REQUEST!

This was an intentional change - the idea was that we keep retrying and the user will deploy a new version of the handler that will fix it. Still up for discussion before it goes GA but for the preview, this is consistent across go/python/java
#2945 (comment)

Same as before, might have gotten unfixed!

This was more just to be in-line with the existing convention - dont fail if unparsable

sdk-java/temporal-sdk/src/main/java/io/temporal/internal/common/LinkConverter.java

Line 162 in 6d09a34

// Swallow un-parsable links since they are not critical to processing

Should we fix for all?

Can you also please comment on this thread #2945 (comment) - unsure about adding 14/15 more overloads but there might be a valid need for it - targeting by runID
@Evanthx

Quinn-With-Two-Ns · 2026-07-23T16:49:21Z

BAD_REQUEST is not retried by default

mavemuri · 2026-07-23T18:52:12Z

BAD_REQUEST is not retried by default

Yes, but was also setting the retry explicitly for that reason- iiuc, this will ensure it will retry
https://github.com/temporalio/sdk-java/pull/2945/changes#diff-b859b54dda09bacf7f8d2fddcb6c9f6727315ceb62f22d472a5cc889bd457507R607

This case is bit odd because it is a bad request- but is retriable so this seemed like the right way to do it

Quinn-With-Two-Ns · 2026-07-23T20:41:21Z

I'd probably capture the validation failure as INTERNAL, but if we did BAD_REQUEST in other SDKs then I am fine with it for now

maciejdudko

Just a few small things, then it should be ready to merge.

maciejdudko · 2026-07-29T13:57:00Z

+        } catch (JsonProcessingException e) {
+          throw new IllegalStateException("failed to generate update operation token", e);
+        }


Under what circumstances can JsonProcessingException happen? Is it user error or server/implementation error? If it's user error then we ought to have better message.

This doesn't catch unchecked exceptions. catch (Exception e) would be a better choice.

It should only be a server error unless the user is trying to manually craft a new token- but that is not the normal case

maciejdudko · 2026-07-29T14:01:12Z

 public enum OperationTokenType {
  UNKNOWN(0),
-  WORKFLOW_RUN(1);
+  WORKFLOW_RUN(1),
+  WORKFLOW_UPDATE(3);


Value 2 is missing. If it's intentional, a comment would be helpful.

maciejdudko · 2026-07-29T14:06:09Z

+      throws OperationException;
+
+  /**
+   * TBD: determine if all the other 14 func+proc+void are required and add if needed Starts a


Change TBD to TODO.

TBD/TODO should not be part of the docstring. Make it a regular comment before docstring.

maciejdudko · 2026-07-29T14:07:46Z

+   * #startWorkflowUpdate(Class, String, Functions.Func1, UpdateOptions)} for the full behavior
+   * contract.
+   *
+   * @param <T>


Doc tag contents are missing for this overload.

Evanthx

A few small things ...

Evanthx · 2026-07-30T23:50:09Z

+          "invalid update request",
+          new IllegalArgumentException(
+              "nexus op workflow updates only support WorkflowUpdateStageAccepted for async updates"),
+          RetryBehavior.RETRYABLE);


If this fails, it will always fail, won't it? So the error shouldn't be RETRYABLE

This was the one discussed here - #2945 (comment)
The idea was that a new version of the handler could be deployed which fixes the wid and it would then start passing
This is consistent with the go/python SDKs temporalio/sdk-go#2417 (comment)

Evanthx

LGTM

mavemuri force-pushed the updates-nexus-op branch 2 times, most recently from 7852a29 to 93ee1a9 Compare July 10, 2026 03:36