Skip to content

Conversation

@jeromepl
Copy link
Contributor

What was changed

Allow using Exception in the workflow_failure_exception_types config option of workers.

Why?

The documentation mentions that using Exception might be useful to allow any error to be considered as a workflow failure:

# @param workflow_failure_exception_types [Array<Class<Exception>>] Workflow failure exception types. This is the
# set of exception types that, if a workflow-thrown exception extends, will cause the workflow/update to fail
# instead of suspending the workflow via task failure. These are applied in addition to the
# `workflow_failure_exception_type` on the workflow definition class itself. If {::Exception} is set, it
# effectively will fail a workflow/update in all user exception cases.

But it was not possible to do so, resulting in a All failure types must classes inheriting Exception error.

@jeromepl jeromepl requested a review from a team as a code owner June 16, 2025 21:11
@jeromepl jeromepl changed the title Allow specifying exception as workflow failure types Allow specifying Exception as workflow failure types Jun 17, 2025
Copy link
Member

@cretz cretz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Yes we support this in other SDKs (basically turning all exceptions into fail-fast workflow failures). Will merge if/when CI passes.

@cretz
Copy link
Member

cretz commented Jun 20, 2025

There is a CI issue unrelated to this PR. We will fix it separately and then merge main back into your branch and then merge this. May not be until next week, thanks for your patience.

@cretz
Copy link
Member

cretz commented Jun 26, 2025

It looks like there may be CI failures for two things not related to this issue (generated protos have a bit of a new format it seems and Rubocop just released a new check). This is kinda our fault for not using a lock file and always running CI, intentionally, against latest versions. I will fix in #291 before I merge it and then will merge main here (and #285).

@cretz cretz merged commit cc5b393 into temporalio:main Jun 27, 2025
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants