[Feature Request] Support ExceptionGroup traceback

[jashandeep-sohi]

Is your feature request related to a problem? Please describe.

I'm using a asyncio.TaskGroup in a workflow to launch and wait for a few activities in parallel. Happy path (seems) to work great, but when there's an exception in the TaskGroup async context manager, that's raised as a ExceptionGroup (PEP 654). Unfortunately, the sub-exception tracebacks are not included in the stack_trace, so it makes debugging a little harder.

Describe the solution you'd like

I think this might stem from the fact you're traceback.format_tb ing the __traceback__ https://github.com/temporalio/sdk-python/blob/d03f356fb65d1044e1182fdc1a4c60a432d420d8/temporalio/converter.py#L832C59-L832C59

I'm wondering if it's possible to use traceback.format_exception to get a output similar to what the Python spits out. That seems to include the sub-exceptions as-well. What's the advantage of using one over the other?

Additional context

[cretz]

I'm wondering if it's possible to use traceback.format_exception to get a output similar to what the Python spits out. That seems to include the sub-exceptions as-well. What's the advantage of using one over the other?

I believe I used format_tb over format_exception because I want just the traceback in our failure stack_trace field, not other exception information or multiple tracebacks.

We don't really have a concept of multiple exceptions in our failure message. I will discuss with the team on how best to support multiple exception stack traces, though it won't help immediately. You'll want to catch/log. But maybe we can just for ExceptionGroup we can use format_exception.

There's another problem with ExceptionGroup - we only fail the workflow on FailureError based exceptions, all others fail the task (which means suspend the workflow until a code fix is deployed to fix the unexpected error). ActivityError is a FailureError so if raised out of the workflow that will fail the workflow, but ExceptionGroup is not that type so it will be treated differently. So really, you'll probably need to catch the exception and re-raise as ApplicationError anyways, and it's at this time you can log if needed.

(feel free to also come discuss details on our #python-sdk channel on our public Slack at https://t.mp/slack if that's easier)

[jashandeep-sohi]

I believe I used format_tb over format_exception because I want just the traceback in our failure stack_trace field, not other exception information or multiple tracebacks.

Oh, I see. The Failure proto has a cause Failure, so you're keeping track of every level individually, that format_exception would also render if used.

My interaction with this field is mostly via the UI where it renders the traceback. As a Python developer I was expecting it to look similar to when an exception is printed by the Python interpreter to the console. And I think for the most part it does.

We don't really have a concept of multiple exceptions in our failure message. I will discuss with the team on how best to support multiple exception stack traces, though it won't help immediately. You'll want to catch/log. But maybe we can just for ExceptionGroup we can use format_exception.

Thanks!

There's another problem with ExceptionGroup - we only fail the workflow on FailureError based exceptions, all others fail the task (which means suspend the workflow until a code fix is deployed to fix the unexpected error). ActivityError is a FailureError so if raised out of the workflow that will fail the workflow, but ExceptionGroup is not that type so it will be treated differently. So really, you'll probably need to catch the exception and re-raise as ApplicationError anyways, and it's at this time you can log if needed.

Yup, that's what I was expecting. I don't want the ExceptionGroup to fail the workflow, I'd just like to be able to see the sub-exceptions' traceback in the UI and try to possibly fix the workflow.

[cretz]

Yup, that's what I was expecting. I don't want the ExceptionGroup to fail the workflow, I'd just like to be able to see the sub-exceptions' traceback in the UI and try to possibly fix the workflow.

We should be logging it on the worker as a task failure (with log line starting with "Failed handling activation on workflow with run ID"). I cannot currently think of a good way to display multiple aggregate exceptions in our model today that would work well. Also the serialized failure has some size limits that could be more easily reached on aggregate exceptions with stack traces. I think for this case, the UI is not going to be better than logs for retrieving this level of detail.

[cretz]

Closing as there is nothing actionable to do here. Exception group is not serializable to a Temporal failure which is a single message w/ a single stack trace and a single cause.