@antonpirker pls rebase/merge master

This can be shipped as soon as getsentry/sentry#48653 is completed and released to production.

Also, for the best experience with exception groups, self-hosted Sentry users should take the corresponding update when it is available.

Hooray! I'm excited to start using this. I updated to 1.24 and tried it out, and I'm not seeing the nested error in the UI yet; it bottoms out at the nursery still. Is there anything I need to do to switch this on?

import trio


async def f():
    raise ValueError("echo")


async def run():
    async with trio.open_nursery() as nursery:
        nursery.start_soon(f)


trio.run(run)

@andyljones - That's because you're only raising one error, and the default behavior for trio is to only raise an exception group if there's more than one error in the group.

To raise an exception group from Trio, you can do either of the following:

• Do at least two things that fail:

  async def run():
      async with trio.open_nursery() as nursery:
          nursery.start_soon(f)
          nursery.start_soon(f)

• Tell Trio that you want to use "strict" mode to always get an exception group regardless of number of errors.

  async def run():
      async with trio.open_nursery(strict_exception_groups=True) as nursery:
          nursery.start_soon(f)

See "Strict" versus "loose" ExceptionGroup semantics in the Trio docs.

The section right before that is also a great introduction to exception groups in Trio.

There's nothing else needed in Sentry, other than updating to 1.24.0 or newer. An event with two ValueErrors raised by Trio looks like this in Sentry:

Note that NonBaseMultiError is an exception defined by Trio that inherits from ExceptionGroup.

Also, just to point out some of the extra work that went into this on the Sentry side, note that an error such as the one shown above will be titled and grouped by the first inner exception:

That's because all exceptions within the group are of the same type and have similar values. Without this, the error would be titled by the root exception, "NonBaseMultiError: multiple tasks failed" - which could make it difficult to distinguish between issues on the issues overview. Also different quantities of inner exceptions of the same type and similar values will be grouped together, rather than separately. (i.e. having ValueError:echo two, three, or four times in the group shouldn't make them different issues.)

Conversely, when the inner exceptions differ significantly - then we'll use the exception group as the title, and group issues based on the combination of the types and values of the inner exceptions. For example:

Will get titled as:

If another of the same exception comes through but the KeyError and IndexError exceptions are swapped, it will still get grouped together as another occurrence of the same issue.