Home / Companies / Temporal / Uncategorized / Page Details

Failure Converter | Temporal Platform Documentation

Uncategorized page from Temporal

Page Details
Company
Word Count
286
Language
English
Contains Code
Unknown
Date Parsed
2025-12-01
Text

On this page

This page discusses Failure Converter.

What is a Failure Converter?

As with input and output, Temporal also uses its own default converter logic for errors that are generated by Workflows. The default Failure Converter copies error messages and call stacks as plain text, and this text output is then directly accessible in the Message field of these Workflow Executions.

This may be undesirable for your application. In some cases, errors could contain privileged or sensitive information that you would need to prevent from leaking or being available via a side channel. Failure messages and call stacks are not encoded as codec-capable Payloads by default; you must explicitly enable encoding these common attributes on failures.

If your errors might contain sensitive information, you can encrypt the message and call stack by configuring the default Failure Converter to use your encoding. This moves your message and stack_trace fields to a Payload that's run through your codec.

For example, with the Temporal Go SDK, you can do this by adding a FailureConverter parameter to your client.Options{} array when calling client.Dial(). The FailureConverter should override the DefaultFailureConverterOptions{} by setting EncodeCommonAttributes: true like so:

c, err := client.Dial(client.Options{
    // Set DataConverter here to ensure that workflow inputs and results are
    // encoded as required.
    DataConverter: mycustom.DataConverter,
    FailureConverter: temporal.NewDefaultFailureConverter(temporal.DefaultFailureConverterOptions{
        EncodeCommonAttributes: true,
    }),
})

If for some reason you need to specify a different set of Converter logic for your Failures, you can replace the NewDefaultFailureConverter with a custom method. For example, if you are both working with highly sensitive data and using a sophisticated logging/observability implementation, you may need to implement different encryption methods for each of them.

Analysis

Location: In the introductory paragraph

Context: "As with input and output, Temporal also uses its own default converter logic for errors that are generated by Workflows. The default Failure Converter copies error messages and call stacks as plain text, and this text output is then directly accessible in the >>>Message<<< field of these Workflow Executions."

Problem: Inconsistent field name casing - "Message" is capitalized here but later in the document it's referenced as lowercase "message" in the code explanation

Fix: Change "Message" to "message" for consistency with the later reference to "message" field


Location: In the Go SDK code example

Context: "For example, with the Temporal Go SDK, you can do this by adding a FailureConverter parameter to your >>>client.Options{}<<< array when calling client.Dial()."

Problem: Technical inaccuracy - client.Options{} is a struct, not an array

Fix: Change "your client.Options{} array" to "your client.Options{} struct"

Product Messaging

No product messaging analysis available for this page.

Competitive Analysis

No competitive analysis available for this page.