Cancel and Signal should still propagate to child workflows after child CAN'ed

[mjameswh]

Is your feature request related to a problem? Please describe.

Given the following sequence:

• A workflow starts a child workflow (call that one A).
• Child workflow A does CAN (that’s B).
• The parent workflow cancels the child workflow (using the run_id of A, as that's the only one it knows).

One would reasonably expect Workflow B to receive the cancellation (same for signals). In fact, this is what indeed happens after the parent workflow closes if child workflow A is started with PARENT_CLOSE_POLICY_REQUEST_CANCEL.

Yet, it appears that, at least in TS, B is not receiving explicit cancellation requests made by the parent workflow.

Describe the solution you'd like

Basically, I believe that server should treat RequestCancelExternalWorkflowExecutionCommandAttributes with a run_id and child_workflow_only = true the same way as first_execution_run_id does in client APIs. Reference..

Things to do

• Add features test to verify current behavior across all SDKs, both for Cancel and Signal.

Per-SDK Tickets

• Go -
• Java -
• Core -
• TypeScript -
• Python -
• .NET -
• PHP -
• Temporal CLI -