feature request: [v4] Failed runs are cached when an idempotencyKey is provided. Add the option to not cache failed runs.

[perostlin]

Provide environment information

System:
OS: macOS 15.4.1
CPU: (10) arm64 Apple M1 Pro
Memory: 133.09 MB / 32.00 GB
Shell: 5.9 - /bin/zsh
Binaries:
Node: 22.14.0 - /usr/local/bin/node
Yarn: 1.22.17 - /usr/local/bin/yarn
npm: 8.11.0 - /opt/homebrew/bin/npm
pnpm: 8.15.6 - /opt/homebrew/bin/pnpm
bun: 1.2.10 - /opt/homebrew/bin/bun

Describe the bug

Hello,

I'm trying to setup Durable Execution, using v4-beta (since 3.3.0 and later doesn't support idempotencyKey).

What I'm currently experiencing is that failed sub task responses are being cached, it feels like completed sub tasks should be cached, but not failed sub tasks.

Maybe I'm missing something, any help is much appreciated!

Reproduction repo

https://github.com/perostlin/trigger.dev-v4-beta

To reproduce

1. Change the "project" in the trigger.config.ts.
2. Run the app and trigger.dev:

pnpm install && pnpm dev && pnpm trigger:dev

3. Test the main task (no payload required).

Additional information

As the screenshot shows it runs the main task two times, the first time the sub-task-2 fails and the second time the sub-task-2 uses cached response.

[nicktrn]

Hey @perostlin, another user recently opened a feature requests for this: https://triggerdev.featurebase.app/p/idempotency-for-non-successful-tasks

Makes a lot of sense to do this and it shouldn't be too hard for us to add an option.

[matt-aitken]

@perostlin I've changed the title because this would definitely be an option we'd add. There are situations where the existing behaviour is useful.

[perostlin]

Thanks for the fast response, @nicktrn and @matt-aitken!

That would be a great option to have, but the documentation for durable execution feels somewhat misleading. If you look at the section below (specifically point 2) it feels like it should be the other way around: an option to cache failed runs.

[Alacon]

@perostlin I've changed the title because this would definitely be an option we'd add. There are situations where the existing behaviour is useful.

It feels like it should be the other way around. An option to cache failed response.
I just cannot think of a scenario where you would like to retry 3 times just to get the exact same failed response.

Happy to hear your thoughts on that @matt-aitken