Open NullOsama opened 1 year ago
This issue was resolved after I downgraded anyio
from 4.0.0
to 3.7.1
I think Sentry should probably handle these in a nicer way
I agree with @rushilsrivastava
Downgrading anyio
may mitigate this issue at hand, but its not a good solution. Sentry should be able to work with the new anyio versions
@NullOsama could you please re-open the issue?
I saw the same when updating to anyio 4. This could still be handled a lot better by Sentry. It's very difficult to find the main error in this output.
Hi @rushilsrivastava, @jacobowitz, @b0g3r, @nickderobertis, are any of you still observing this issue? If so, I will gladly reopen it 🙂
are any of you still observing this issue? If so, I will gladly reopen it 🙂
Yes, this still happens on newer version of anyio
@rushilsrivastava Thanks for that info, I have reopened this issue on our backlog.
Exactly which versions of anyio are you experiencing the problems with? And, how do I reproduce the issue?
Same over here with both anyio
4.4.0
and 4.3.0
with sentry-sdk
2.4.0
.
So if I got this right, this is happening with anyio
version 4.0.0
and above. Took a look at the changelog, these two points look relevant:
- BACKWARDS INCOMPATIBLE Replaced AnyIO’s own ExceptionGroup class with the PEP 654 BaseExceptionGroup and ExceptionGroup
- BACKWARDS INCOMPATIBLE Changes to cancellation semantics:
- Any exceptions raising out of a task groups are now nested inside an ExceptionGroup (or BaseExceptionGroup if one or more BaseException were included)
- Fixed task group not raising a cancellation exception on asyncio at exit if no child tasks were spawned and an outer cancellation scope had been cancelled before
- Ensured that exiting a TaskGroup always hits a yield point, regardless of whether there are running child tasks to be waited on
- On asyncio, cancel scopes will defer cancelling tasks that are scheduled to resume with a finished future
- On asyncio and Python 3.9/3.10, cancel scopes now only suppress cancellation exceptions if the cancel message matches the scope
- Task groups on all backends now raise a single cancellation exception when an outer cancel scope is cancelled, and no exceptions other than cancellation exceptions are raised in the group
It looks like anyio
changed the semantics of the exceptions raised.
Is the problem that the "good" exception y'all would like to see is still there, but hidden somewhere in the exception group?
If someone could provide a small example to repro to help us understand the issue better, that'd help a lot.
@antonpirker forgive me, what's the plan here?
I see that it's been removed from the milestone by you, care to provide some context?
Hey @bruno-gelb ! I just removed all our milestones because we kind of did not use them the correct way. There has been no change in priority for this, we just do not use milestones anymore. Sorry for any confusion that might have caused.
tested "pin anyio to <4" fix and it worked for me.
tl;dr for this issue:
1) With anyio
version 4.0.0
anyio is using Pythons ExceptionGroups instead of a custom exception group implementation they used earlier.
2) Sentry handles exception groups different than simple exceptions to show how the exceptions in an exception group are related.
3) You (the persons in this thread) do not like how the exception group is displayed in Sentry.
To everyone in the thread (also the ones that only "thumb up" on comments:
1) Can you find your error in the exception group? 2) How can we improve the exception group display? Any ideas? 3) Is data missing you used to see before? 4) any other ideas on how to make things better?
ZeroDivisionError: division by zero
, not Exception group: unhandled errors in TaskGroup (1 sub-exception)
How do you use Sentry?
Sentry Saas (sentry.io)
Version
1.29.2
Steps to Reproduce
I'm not sure if it's something I did recently but the errors started to all have the same generic title
ExceptionGroup
unhandled errors in a TaskGroupExpected Result
The way I expected the error to be shown is how it was before as shown in the following screenshots.
Actual Result
The previous screenshot shows how is the exception shown which is very different from what it was before and it doesn't show specific information about the actual error. BTW, these screenshots are of the same error but something happened that made it look like the later pic.