Ability for certain task failure types to fail workflow #516
Conversation
| # Also, we have to re-import the worker-level exception types, because | ||
| # some exceptions are not passthrough and therefore our issubclass fails | ||
| # because it'll be comparing out-of-sandbox types with in-sandbox types |
There was a problem hiding this comment.
eww, that kinda sucks. Not that there's anything to be done about it really I guess, but, eww.
There was a problem hiding this comment.
I couldn't think of a better way and I'm sure TS will have this problem too. Basically we want to support subtype checking for this, but in some cases Python sandbox reloads a user type inside the sandbox and it'll fail to match what was set outside the sandbox.
Another option here would be to not allow this to be set on the worker but instead make a new interceptor method that could be overridden to determine whether an exception was task fail or workflow fail. But I figured reloading was the best from a user POV.
There was a problem hiding this comment.
Yeah this is definitely better for the user. Hopefully not fragile.
There was a problem hiding this comment.
It is a bit fragile for advanced cases, but this is what that "prepare workflow" concept is for. It creates a workflow in the sandbox on worker start just as if it got work for that workflow in an attempt to fail quickly for anything not sandbox compatible. We also make sure that none of this applies if the user didn't opt-in to this experimental setting.
What was changed
workflow_failure_exception_typestoWorkerto allow configuring failure exception types at a worker levelfailure_exception_typesto@workflow.defnto allow configuring failure exception types at a workflow leveltemporalio.workflow.NondeterminismError(or super type) in worker/workflow optionsIt's no coincidence this mimics temporalio/sdk-dotnet#205. Also see the feature issue at temporalio/features#322.
Checklist