[atol]

What was changed

• Signals and Signal-With-Starts sent through TemporalNexusClient.getWorkflowClient() in a @TemporalOperation handler now reuse the Nexus operation's request ID.
• Breaking (experimental API): each handler run can send only one such signal; a second throws a BAD_REQUEST error. Signal-With-Start counts toward the limit; a failed signal doesn't; a retried Nexus task starts with a fresh limit.
• Breaking (experimental API): Signal-With-Start from such a handler requires an explicit workflow ID.
• Nexus.getOperationContext().getWorkflowClient() returns the same client, so signals sent through it from a @TemporalOperation handler are covered too. Signals from other Nexus handlers (e.g. OperationHandler.sync, WorkflowRunOperation), or from threads other than the handler thread, are unchanged.
• Based on De-duplicate Nexus Signal and SignalWithStart operations sdk-go#2781.

Why?

When a Nexus task is retried, the handler reruns and sends its signal again with a new random request ID, so the workflow receives it twice. Reusing the operation's request ID lets the server dedupe the retry. However, every signal in one handler run then shares that ID, so a second signal to the same workflow would be silently dropped while reported as delivered. Limiting each run to one signal turns that silent loss into a clear error. Signal-With-Start also requires an explicit workflow ID, since a generated one would differ on each retry and start a second workflow instead of deduping.

Checklist

1. How was this tested:
   Added unit and integration tests.

2. Any docs updates needed?
   No.

[Quinn-With-Two-Ns]

Breaking (experimental API): Signal-With-Start from such a handler requires an explicit workflow ID.

Can you expand on this ,, are you saying signal-with-start didn't require a workflow ID before?

[Quinn-With-Two-Ns]

I think it would be better to move this up to the docs on TemporalNexusClient where we talk about sending a signal from a TemporalOperation, also this is quite verbose don't you think?

[atol]

Yep, I can move and shorten the comment.

[Quinn-With-Two-Ns]

Breaking (experimental API): Signal-With-Start from such a handler requires an explicit workflow ID.

Can you expand on this ,, are you saying signal-with-start didn't require a workflow ID before?

[atol]

Breaking (experimental API): Signal-With-Start from such a handler requires an explicit workflow ID.

Can you expand on this ,, are you saying signal-with-start didn't require a workflow ID before?

Before, the workflow ID for Signal-with-Start was derived from getWorkflowIdForStart(), which would default to a new UUID if the workflow ID is not set on WorkflowOptions:

sdk-java/temporal-sdk/src/main/java/io/temporal/client/WorkflowStubImpl.java

Lines 212 to 218 in de77db8

	private static String getWorkflowIdForStart(WorkflowOptions options) {
	String workflowId = options.getWorkflowId();
	if (workflowId == null) {
	workflowId = UUID.randomUUID().toString();
	}
	return workflowId;
	}

But since the server only matches request IDs within the same workflow run, we need a consistent workflow ID for deduplication.

Python, TypeScript and .NET already require a workflow ID for Signal-with-Start. I added a similar check in Go in temporalio/sdk-go#2781.