Worker/workflow-level hook to react to every workflow's terminal outcome (success/failure)
#492 创建于 2026年6月17日
仓库指标
- 星标
- (183 个星标)
- PR 合并指标
- (PR 指标待抓取)
描述
Is your feature request related to a problem? Please describe
We run a set of YAML workflows and need to react to each workflow's terminal outcome (success and failure) to update an external system — record status, the failure reason, etc. The constraint: we want this generically, configured once, not by adding a try/catch + status-report step to every activity in every YAML.
There's no built-in way to run logic on a workflow's terminal outcome across all workflows without per-activity/per-workflow boilerplate, so today we poll the Temporal Visibility API from an external service to detect failures.
Describe the behaviour you'd like
A worker- or workflow-level hook that fires on every workflow's terminal close, registered once (not per-workflow YAML, not per-activity). Conceptually an onComplete / onFailure callback or interceptor that receives:
- the workflow input and/or custom search attributes,
- the terminal status (
succeeded/failed/timed_out/terminated/canceled), - for failures, the error message / reason.
So a single registered handler can react to outcomes for all workflows.
Describe alternatives you've considered
- Per-activity try/catch + status step — works, but it's boilerplate in every activity of every workflow.
use.catalogreusable blocks (#316) — reduces duplication, but wrapping every activity still means referencing the block per activity, so the boilerplate remains.- CloudEvents (
docs/dsl/debugging) — observability only: there'sworkflow.completedbut no terminalworkflow.faulted, the payload doesn't carry workflow input / search attributes / failure reason, and sinks are file/HTTP only. - Nexus (#141) — on the roadmap, not available today.
- External Temporal Visibility polling — what we do now; it works, but it's a separate poller with its own checkpoint/dedup concerns and can't see in-workflow failure detail without extra history fetches.
Additional context
This is a common need (status reporting / alerting / external-system sync) that currently forces either per-activity boilerplate or an out-of-band watcher. A generic terminal-outcome hook would let us capture outcomes in-workflow and retire the external poller.
One concrete option, if a full hook is heavy: extend the existing CloudEvents to emit a terminal workflow.faulted event carrying input/search-attributes + failure reason to a consumable sink.
Happy to contribute a PR once the shape is agreed.
Describe the behaviour you'd like
A worker- or workflow-level hook that fires on every workflow's terminal close, registered once (not per-workflow YAML, not per-activity). Conceptually an onComplete / onFailure callback or interceptor that receives:
- the workflow input and/or custom search attributes,
- the terminal status (
succeeded/failed/timed_out/terminated/canceled), - for failures, the error message / reason.
So a single registered handler can react to outcomes for all workflows.