signalWithStart drops Priority (priority/fairness) set on WorkflowOptions

[MattSilvaa]

Expected Behavior

WorkflowClient.signalWithStart should honor the Priority set on WorkflowOptions (priorityKey, fairnessKey, fairnessWeight) and send it to the server, the same way a plain WorkflowClient.start / WorkflowStub.start does. The entry point should not change the priority/fairness the server sees for identical options.

Actual Behavior

The Priority is silently dropped on signalWithStart, so the same WorkflowOptions produce different server-side behavior depending on whether the workflow is started via start or signalWithStart. Because fairness lives inside the same Priority proto, fairnessKey and fairnessWeight are lost for the same reason.

Root cause is in WorkflowClientRequestFactory.newSignalWithStartWorkflowExecutionRequest. It builds the signalWithStart request by copying fields off the already-built start request (retryPolicy, memo, searchAttributes, header, startDelay, userMetadata, versioningOverride) but never copies priority. The newStartWorkflowExecutionRequest path does set priority, so the plain start path is unaffected.

Steps to Reproduce the Problem

1. Build WorkflowOptions with a non-default setPriority(...) (e.g. priorityKey, fairnessKey, fairnessWeight) and a task queue.
2. Start the workflow via WorkflowClient.signalWithStart(...) instead of start(...).
3. Inspect the SignalWithStartWorkflowExecutionRequest sent to the server: priority is unset, whereas the same options sent via start carry it.

Specifications

• Version: 1.37.0 (also affects earlier versions that support priority/fairness)
• Platform: Java SDK, all platforms

[MattSilvaa]

Fix in progress: #2968