signalWithStart never propagates WorkflowOptions.priority, despite the proto field existing

[vathsalaR]

Expected Behavior

signalWithStart should propagate WorkflowOptions.priority the same way start() does, since the underlying proto already supports it.

Actual Behavior

WorkflowStub.signalWithStart(...) (and the higher-level WorkflowClient.signalWithStart(BatchRequest) wrapper, which calls the same underlying method) never sends Priority on the wire, even when set via WorkflowOptions.newBuilder().setPriority(...). A workflow started this way shows no priority field at all in its WorkflowExecutionStarted history event.

Steps to Reproduce the Problem

1.WorkflowOptions options = WorkflowOptions.newBuilder()
.setTaskQueue("my-task-queue")
.setWorkflowId("my-workflow-id")
.setPriority(Priority.newBuilder().setPriorityKey(1).build())
.build();
WorkflowStub stub = client.newUntypedWorkflowStub("MyWorkflow", options);
stub.signalWithStart("mySignal", new Object[]{signalArg}, new Object[]{startArg});
2.Decode the resulting WorkflowExecutionStarted event — no priority field, regardless of the priorityKey set.

Specifications

• Version:confirmed identical (missing) in SDK sources from 1.31.0 through the latest 1.37.0 — not fixed in any release since Priority was introduced.
• Platform:

[MattSilvaa]

+1 Seeing this issue on Java SDK