message-passing/signals

5 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Signal deduplication using caller-supplied id to detect duplicate Signal deliveries

Temporal delivers Signals with at-least-once semantics: client retries, flaky networks, or over-eager UIs can submit the same correction multiple times and the Workflow will see both copies. Defend against duplicate Signal processing by storing an optional id field on FixEntry objects in the fix history audit trail. When a Signal arrives with an id, check if fixHistory.some((f) => f.id === update.id). If found, log a warning and return early without re-applying the patch. The client (dashboard, CLI script, or automated agent) is responsible for generating a stable id per logical correction—typically a UUID minted when the operator clicks 'Patch and Retry', reused across any retries of that same submission.

Signal handler patches application data in-place to correct persistent state

In the Signal handler, apply corrections directly to the mutable application data object. For example: (app as any)[key] = parseFloat(update.value ?? '0') for numeric fields or (app as any)[key] = update.value ?? '' for strings. Record the correction in fixHistory with the activity name, field, old value, new value, error message that triggered the fix, and optional id for deduplication. After patching the data, set retryRequested = true to wake any paused condition(). The next iteration of the recoverableStep loop will retry the failed Activity with the corrected data without re-executing any previously completed Activities.

Example: Signal handler with deduplication and data patching

```typescript setHandler(retrySignal, (update: RetryUpdate) => { // Deduplicate via caller-supplied id if (update.id && fixHistory.some((f) => f.id === update.id)) { log.warn(`Duplicate retry signal ignored: ${update.id}`); return; } if (update.key) { const key = update.key as keyof LoanApplication; const oldValue = String((app as any)[key]); // Parse numeric fields as numbers if (key === 'annualIncome' || key === 'loanAmount' || key === 'downPayment') { (app as any)[key] = parseFloat(update.value ?? '0'); } else { (app as any)[key] = update.value ?? ''; } // Record correction in audit trail fixHistory.push({ activity: failedActivity, field: key, oldValue, newValue: update.value ?? '', error: failureMessage, id: update.id, }); log.info(`Fix received ${key}: ${oldValue} -> ${update.value}`); } else { log.info('Retry requested without patch'); } // Wake the paused condition() to retry the failed Activity retryRequested = true; }); ``` The handler patches application data in-place, deduplicates via id, records the fix in fixHistory, and wakes the paused Workflow.

Signal mechanism for sending data to a running Workflow

Signals are the mechanism for sending data to a running Workflow without affecting its execution result. In the approval pattern, signals are used to submit approval decisions (approval, rejection, or changes requested) and to withdraw documents. The Workflow defines signal handlers using the @workflow.signal decorator. When a Signal is sent via the client, it is delivered to the Workflow and a new Workflow Task is scheduled to process the signal handler.

Withdrawal signal for cancelling approval

The Workflow supports a withdraw() signal that allows the document submitter to cancel the approval process at any time. When the withdraw signal is received, the Workflow sets status to WITHDRAWN. If the Workflow is waiting for a decision, the wait_condition immediately unblocks and returns an ApprovalDecision with status REJECTED. The Workflow then records a DOCUMENT_WITHDRAWN audit entry and completes. If withdrawal occurs during the resubmission window after changes were requested, the Workflow records DOCUMENT_WITHDRAWN and completes without allowing further resubmission.

Give your agent this brain