Send and handle Signals, Queries, and Updates on a running Temporal workflow, including signal-with-start

Documented steps

1. Define handlers in the workflow: Python `@workflow.signal`, `@workflow.query`, `@workflow.update` (an update may be paired with a `@<handler>.validator` method that must be synchronous and return None). TypeScript: `wf.defineSignal<[Args]>('name')`, `wf.defineQuery<Ret,[Args]>('name')`, `wf.defineUpdate<Ret,[Args]>('name')`, then inside the workflow function call `wf.setHandler(def, fn, { validator })`.
2. Send a signal from a client: Python `await handle.signal(MyWorkflow.my_signal, args)`; TypeScript `await handle.signal(mySignal, payload)`. The call returns once the server accepts the signal, without waiting for a worker to process it.
3. Send a query: Python `await handle.query(MyWorkflow.my_query, args)`; TypeScript `await handle.query(myQuery, args)`. Queries are synchronous, never enter Event History, and require an online worker. They can target a completed execution; the built-in `__stack_trace` query is the exception and only works on running executions.
4. Send an update and wait for its result: Python `await handle.execute_update(MyWorkflow.my_update, args)`; TypeScript `await handle.executeUpdate(myUpdate, { args: [...] })`. To obtain a handle before completion use Python `start_update(..., wait_for_stage=WorkflowUpdateStage.ACCEPTED)` or TypeScript `handle.startUpdate(myUpdate, { args, waitForStage: WorkflowUpdateStage.ACCEPTED })`, then call `.result()` later.
5. Use signal-with-start to atomically start the workflow if it is not already running and always deliver the signal: Python `client.start_workflow(MyWorkflow.run, id=..., task_queue=..., start_signal="my_signal", start_signal_args=[...])`; TypeScript `client.workflow.signalWithStart(MyWorkflow, { workflowId, taskQueue, args, signal: mySignal, signalArgs: [...] })`.
6. For update-with-start use Python `client.execute_update_with_start_workflow(...)` / `start_update_with_start_workflow(...)` or the TypeScript equivalent with a `WithStartWorkflowOperation`. It requires an explicit `WorkflowIDConflictPolicy`, and the docs state that unlike signal-with-start it is NOT atomic. For self-hosted users the docs recommend Temporal Server v1.28.
7. Guard shared workflow state against interleaving: the docs state messages can run interleaved with the main workflow and with one another, so wrap async signal/update handlers that mutate state in an `asyncio.Lock` (Python) or a `Mutex` via `lock.runExclusive` (TypeScript).
8. Add an update validator to reject bad input before it enters history: Python decorate a sibling method with `@my_update.validator` (must be non-async, return None, raise to reject); TypeScript pass `validator` in `setHandler` options (must be synchronous). A rejected update records no `WorkflowExecutionUpdateAccepted` event.
9. Before the workflow's main method returns or continues-as-new, drain outstanding handlers: Python `await workflow.wait_condition(workflow.all_handlers_finished)`; TypeScript `await wf.condition(wf.allHandlersFinished)`. Suppress the resulting worker warning per handler with `unfinished_policy=workflow.HandlerUnfinishedPolicy.ABANDON` (Python) or the `unfinishedPolicy` option (TypeScript).
10. When a workflow is started via signal-with-start, or a worker picks it up late, handlers can run before the main method's first execution. In Python use the `@workflow.init` decorator on `__init__` so state is initialized from workflow input before any handler runs.
11. Reference docs: https://docs.temporal.io/sending-messages | https://docs.temporal.io/handling-messages | https://docs.temporal.io/develop/python/message-passing | https://docs.temporal.io/develop/typescript/message-passing