# Panicing within a DataConverter and/or PayloadCodec

**URL:** <https://community.temporal.io/t/panicing-within-a-dataconverter-and-or-payloadcodec/19305>\
**Category:** Community Support\
**Tags:** go-sdk, general-impl\
**Created:** [February 24, 2026, 7:18pm UTC](https://community.temporal.io/t/panicing-within-a-dataconverter-and-or-payloadcodec/19305 "2026-02-24T19:18:41Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![hferentschik](https://avatars.discourse-cdn.com/v4/letter/h/91b2a8/32.png) [@hferentschik](https://community.temporal.io/u/hferentschik)\
**Post date:** [February 24, 2026, 7:18pm UTC](https://community.temporal.io/t/panicing-within-a-dataconverter-and-or-payloadcodec/19305/1 "2026-02-24T19:18:41Z")

</div>

Hi there,

We are using the [temporal-large-payload-codec](https://github.com/DataDog/temporal-large-payload-codec) to work around the size limitations of Temporal in- and outputs. This works great, except we had situations where we got non determinism errors, namely when the connection to the underlying bucket is interrupted or delayed.

Based on the current interface design of the `PayloadCodec` an error is returned from `Encode` respectively `Decode`. The interface methods are:

```auto
Encode([]*commonpb.Payload) ([]*commonpb.Payload, error)

Decode([]*commonpb.Payload) ([]*commonpb.Payload, error)

```

Atm, when there is no network connection, the implementation of these function will hang and then once the client connection times out (in our case a very high timeout of 60s) return an error.

The problem occurs in the workflow implementation where we have a call to a future:

```auto
err := fut.Get(ctx, &result);

```

It can occur that the actual called activity executed and is recorded in the history, but then on the `Get` call the retrieval via the codec fails. This will return an error. In our code we don’t distinguish between a workflow error or a codec error and the code takes some compensating actions based on the error. When this workflow gets replayed at a later stage, the codec might then be able to decode the payload and no error is returned and the code takes a different path leading to a non determinism error.

What we are asking ourself is whether it would be better to panic in the codec in case of an error. This should then be handled by the workflows panic handler/policy and a non determinism error should not occur.

Or is it better to wrap errors in `ErrUnableToEncode`/`ErrUnableToDecode` (see [errors.go](https://github.com/temporalio/sdk-go/blob/f39757a0e7f5368a2634899e9008ead80f41d1cc/converter/errors.go#L39-L41)) and check the error type of `future.Get`?

Any ideas?

Thanks,

Hardy

---

<div class="post-metadata">

**Author:** ![maxim](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/maxim/32/8_2.png) [@maxim](https://community.temporal.io/u/maxim)\
**Post date:** [February 25, 2026, 5:56am UTC](https://community.temporal.io/t/panicing-within-a-dataconverter-and-or-payloadcodec/19305/2 "2026-02-25T05:56:20Z")

</div>

Yes, you should panic on codec error to force workflow task failure and its retry. Returning error from an IO operation is not allowed as it is not deterministic.

---

<div class="post-metadata">

**Author:** ![hferentschik](https://avatars.discourse-cdn.com/v4/letter/h/91b2a8/32.png) [@hferentschik](https://community.temporal.io/u/hferentschik)\
**Post date:** [February 25, 2026, 9:53am UTC](https://community.temporal.io/t/panicing-within-a-dataconverter-and-or-payloadcodec/19305/3 "2026-02-25T09:53:13Z")

</div>

Thanks for the quick replz @maxim