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

Quinn-With-Two-Ns · 2026-07-10T18:29:03Z

    if (commonLink.hasNexusOperation()) {
      return nexusOperationToNexusLink(commonLink.getNexusOperation());
    }
+    // check for workflow link only if a more specific variant is not set


Nit: I don't think this comment makes sense, we are just checking variants here and there can only be one

fixed - misread it as hasWorkflowID initially

Quinn-With-Two-Ns · 2026-07-10T18:30:05Z

+import org.junit.ClassRule;
+import org.junit.Test;
+
+public class UpdateWorkflowOperationTest extends BaseNexusTest {


Shouldn't need to inherit from BaseNexusTest, we should probably mark it as deprecated or remove it. (not saying do that in this PR)

Any reason for removing it? looks useful as a utility

All the utility is already in the SDK rule

Quinn-With-Two-Ns · 2026-07-10T18:31:40Z

+      effectiveOptsBuilder.setUpdateId(requestId);
+    }
+    if (options.getWaitForStage() == null) {
+      effectiveOptsBuilder.setWaitForStage(WorkflowUpdateStage.ACCEPTED);


Oh WaitForStage should be explicitly set, that is the clients behaviour so we should try to match that here

Ah ok wanted to see if we could make it easier with a default callout - stricter makes sense, will change

Quinn-With-Two-Ns · 2026-07-10T18:34:54Z

+            if (input.getUpdateId() != null) {
+              optionsBuilder.setUpdateId(input.getUpdateId());
+            }
+            return client.startWorkflowUpdate(


The Nexus client wasn't intended to take the stubs. The proposed API was to take the unbound method reference like all new Java SDK APIs like

public <T, A1, R> TemporalOperationResult<R> updateWorkflow( String workflowId, Class<T> workflowClass, unctions.Func2<T, A1, R>> updateMethod, A1 arg);

We should discuss if the proposed API does not work

Quinn-With-Two-Ns · 2026-07-10T18:37:46Z

+  // only set for updates
+  private final String updateId;
+
  public OperationToken(


Could consider splitting the OperationToken into different Java types for the different t. Should be possible using jackson. Although I would be fine defering this until we have activities here as well and then doing the refactor then

Thought about it with a base class that does common encode/decodes but left it as overloads give hints and the remaining is mostly similar
But agree on maybe changing after activities- if changing here, will track in other SDKs too for consistency

Quinn-With-Two-Ns · 2026-07-10T18:39:49Z

+ * cancel.
+ */
+@Experimental
+public final class CancelUpdateWorkflowExecutionInput {


Suggested change

public final class CancelUpdateWorkflowExecutionInput {

public final class CancelUpdateWorkflowInput {

I thought we would call it CancelUpdateWorkflowInput ,open to other ideas though, regardless we should make sure we are consistent across all the SDKs and docs here.

makes sense, fixed

Quinn-With-Two-Ns · 2026-07-10T18:40:10Z

+
+  /** Returns the run ID extracted from the operation token, or null if not present. */
+  @Nullable
+  public String getRunId() {


I think for CancelUpdateWorkflowInput this is always non null

There are 2 cases -

Right now, we are generating it based on the input - if user provides no runID, there wont be one in the token
Not sure if we need to grab it from a handle either - intent of user could be that they want to just run an update on current workflow run - but for cancel its not clear if the cancel should also "preserve" that original intent - i thought it should
eg. run update- without specifying runID- while workflow is on runID1, get token. Now, when workflow is on runID2, still want to cancel the update => the current token will work
OTOH, if they specifically had a runID, then it wont work but that is stricter and is fully consistent with what they need
This is consistent across the go/python/java SDK PRs
But we can discuss if this preserving original intent means getting runID via handle if empty- or if thats decided already

user just wants to cancel it, crafts the encoded token themselves without runID to cancel current one. Required for above case as well if token was initially minted with a specific runID

changed it to empty string default but i think its still same functionally

We should not be generating based on the input, we should generate based on the output of the update response. Updates do not move between runs so please use the run ID of the update.

Please also make sure you fix this in Go as well this needs to encode where the workflow update actually is so this is blocker for the Go SDK as well

Evanthx · 2026-07-10T18:38:26Z

+      if (nexusOperationMetadata.operationCompleted) {
+        try {
+          R value = handle.getResult();
+          return TemporalOperationResult.sync(value);


This vranch doesn't call asyncOperationStarted.set(false) - does it need to? It looks like it is left set to true.

The asyncOperationStarted is more of a guard against multiple invocations using the same ephemeral nexusClient. Whether it completed sync or async is the result and isnt tied to how the req was made - because in either case, request itself was always an asyncReq
Only case where it resets to false is if the op can be retried safely- due to real issues like op failing due to invalid params etc

Evanthx · 2026-07-10T18:45:50Z

+  private <R> void checkNexusUpdateOptionsValid(UpdateOptions<R> options) {
+    if (options.getWaitForStage() != WorkflowUpdateStage.ACCEPTED) {
+      throw new HandlerException(
+          HandlerException.ErrorType.BAD_REQUEST,


Go returns this as a nexus.OperationError - should this be consistent?

agree, fixed

Evanthx · 2026-07-10T18:49:46Z

+          URLEncoder.encode(w.getWorkflowId(), StandardCharsets.UTF_8.toString())
+              .replace("+", "%20"); // handle workflowIds supporting spaces
+      String runId = URLEncoder.encode(w.getRunId(), StandardCharsets.UTF_8.toString());
+      String url = String.format(linkPathFormat, namespace, workflowId, runId);


String.format can throw IllegalFormatException which is uncaught - should you just catch Exception instead of limiting it?

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

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

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

View reviewed changes

Evanthx requested changes Jul 10, 2026

View reviewed changes

mavemuri added 3 commits July 10, 2026 20:44

Upgrade temporal-api to v1.62.14

7c88e30

NEXUS-485: Support Workflow Update as a Nexus Operation

e087e0e

address comments, change signatures to newer

ba6377e

mavemuri force-pushed the updates-nexus-op branch from 1758efd to ba6377e Compare July 11, 2026 03:44

	public final class CancelUpdateWorkflowExecutionInput {
	public final class CancelUpdateWorkflowInput {

Uh oh!

Conversation

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

Uh oh!

What was changed

Why?

Checklist

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!

mavemuri Jul 11, 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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

mavemuri commented Jul 10, 2026 •

edited

Loading

mavemuri Jul 11, 2026 •

edited

Loading