Is your feature request related to a problem? Please describe.
Each SDK currently makes a hardcoded choice about how that failure is logged. The application, however, has the context that would make the log actionable, but must log separately and rely on correlation IDs to provide the context.
Adding an SDK exception handler interface that is called when an exception leaks would allow the application to provide actionable log messages. While I'm talking specifically about logs here, I would see our use also hooking into telemetry, etc.
The handler should be written in such a way that the contract is consistent across SDKs. If the handler is undefined, it would default to the current implementation.
The four SDKs we use (Go, Java, Python, TypeScript) already disagree on what to do here, but the benefit of introducing an interface would benefit all SDKs:
| SDK |
Site / level |
Message |
| Java |
WorkflowExecutionHandler#throwAndFailWorkflowExecution — WARN |
"Workflow execution failure WorkflowId='{}', RunId={}, WorkflowType='{}'" |
| Go |
internal_task_handlers.go applyWorkflowPanicPolicy — Error |
"Workflow panic" + workflow/run/attempt/error/stack tags |
| Python |
_workflow_instance.py — WARNING |
"Failed activation on workflow ...", extra={"__temporal_error_identifier": "WorkflowTaskFailure"} |
| TypeScript |
worker.ts — error |
"Failed to process Workflow Activation" — but only fires for unhandled-rejection / SDK-internal paths; normal user-thrown exceptions silently become a failed completion with no TS-side log |
Existing extension points don't compose:
- Pluggable loggers (Go
ClientOptions.Logger, TS Runtime.install({logger})) are client/process-wide, not failure-aware.
- Worker interceptors miss framework-internal failure paths (e.g. Java's
runConstructor) and the SDK's own log still fires after them.
- Logging-framework filters (SLF4J turbo-filters, Python
logging.Filter against __temporal_error_identifier) work but lean on internal class names, message strings, and extras the SDK doesn't promise to keep stable.
Describe the solution you'd like
Add a per-SDK exception handler invoked when a workflow or activity leaks an uncaught exception, so the application decides how that failure is logged.
Additional context
Once we agree on a contract, we would be willing to implement for some of the SDKs: starting first with Java, then our other paved road (Go, Python, TypeScript) as our capacity allows (:fingerscrossed: EOY26).
Per-SDK Tickets
Is your feature request related to a problem? Please describe.
Each SDK currently makes a hardcoded choice about how that failure is logged. The application, however, has the context that would make the log actionable, but must log separately and rely on correlation IDs to provide the context.
Adding an SDK exception handler interface that is called when an exception leaks would allow the application to provide actionable log messages. While I'm talking specifically about logs here, I would see our use also hooking into telemetry, etc.
The handler should be written in such a way that the contract is consistent across SDKs. If the handler is undefined, it would default to the current implementation.
The four SDKs we use (Go, Java, Python, TypeScript) already disagree on what to do here, but the benefit of introducing an interface would benefit all SDKs:
WorkflowExecutionHandler#throwAndFailWorkflowExecution—WARN"Workflow execution failure WorkflowId='{}', RunId={}, WorkflowType='{}'"internal_task_handlers.go applyWorkflowPanicPolicy—Error"Workflow panic"+ workflow/run/attempt/error/stack tags_workflow_instance.py—WARNING"Failed activation on workflow ...",extra={"__temporal_error_identifier": "WorkflowTaskFailure"}worker.ts—error"Failed to process Workflow Activation"— but only fires for unhandled-rejection / SDK-internal paths; normal user-thrown exceptions silently become a failed completion with no TS-side logExisting extension points don't compose:
ClientOptions.Logger, TSRuntime.install({logger})) are client/process-wide, not failure-aware.runConstructor) and the SDK's own log still fires after them.logging.Filteragainst__temporal_error_identifier) work but lean on internal class names, message strings, and extras the SDK doesn't promise to keep stable.Describe the solution you'd like
Add a per-SDK exception handler invoked when a workflow or activity leaks an uncaught exception, so the application decides how that failure is logged.
Additional context
Once we agree on a contract, we would be willing to implement for some of the SDKs: starting first with Java, then our other paved road (Go, Python, TypeScript) as our capacity allows (:fingerscrossed: EOY26).
Per-SDK Tickets