You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
strict_exception_groups is documented as making the exception structure that comes out of a nursery aexit not depend on whether == 1 or > 1 tasks raised, by having a strict nursery always wrap all exception(s) in a new group:
If [strict_exception_groups is] true, nurseries will always wrap even a single raised exception in an exception group.
but on master this isn't happening:
minimized reproducer 1
importtrioasyncdefeg() ->None:
asyncdefraiser() ->None:
raiseRuntimeError("boom")
asyncdeff() ->None:
asyncwithtrio.open_nursery(strict_exception_groups=True) asinner:
inner.start_soon(raiser)
asyncwith (
# A similar bug also occurs if there are more strict nurseries open here:# trio.open_nursery(strict_exception_groups=True),trio.open_nursery(strict_exception_groups=True) asnursery,
):
n=2# try uncommenting me! it completely changes the exception structure.# n = 1for_inrange(n):
nursery.start_soon(f)
trio.run(eg)
expected: the same exception structure with n = 1 and n > 1, i.e. two levels of exception groups (or three if the third nursery is uncommented).
the task's crash is in only one one exception group, even though it occurred two strict nurseries down the stack. (similarly, if you uncomment the extra nursery, it's still only one when it should be three.)
while this new behavior will not break except* usage (because except* recurses), it is still a problem. for example:
minimized reproducer 2
importtrioasyncdefeg() ->None:
asyncdefraiser() ->None:
exc_group_from_some_task=ExceptionGroup(
"some error message", (RuntimeError("boom"),)
)
exc_group_from_some_task.add_note("some note")
raiseexc_group_from_some_tasktry:
asyncwithtrio.open_nursery(strict_exception_groups=True) asnursery:
nursery.start_soon(raiser)
exceptBaseExceptionGroupasnursery_exc_group:
raiseBaseExceptionGroup(
"a useful error message instead of just the (necessarily) vague MultiError repr",
nursery_exc_group.exceptions,
) fromNone# Note: `strict_exception_groups=True` guarantees that the `nursery_exc_group` we caught# here is a brand new one that the nursery created, and NOT an exception group# that came out of one of `nursery`'s tasks.trio.run(eg)
expected: two exception groups, and trio doesn't cause your exception group messages/notes to be hidden:
+ Exception Group Traceback (most recent call last):
| ...
| ExceptionGroup: a useful error message instead of just the (necessarily) vague MultiError repr (1 sub-exception)
+-+---------------- 1 ----------------
| ...
| ExceptionGroup: some error message (1 sub-exception)
| some note
+-+---------------- 1 ----------------
| RuntimeError: boom
+------------------------------------
observed: one exception group, and trio causes some exception group messages/notes to be hidden:
+ Exception Group Traceback (most recent call last):
| ...
| ExceptionGroup: a useful error message instead of just the (necessarily) vague MultiError repr (1 sub-exception)
+-+---------------- 1 ----------------
| RuntimeError: boom
+------------------------------------
details
i encountered this regression while testing a downstream work against trio master in preparation for the upcoming v0.23 release.
this bisects to #2826 (CC @jakkdl). from its newsfragment, tests, and surrounding discussions, my understanding is that #2826's primary intent was to hide the implementation-detail nursery of start (i.e. to resolve #2611)—but that it did not intend to make trio violate its strict_exception_groups docs & also hide third-party exception messages from tracebacks.
The text was updated successfully, but these errors were encountered:
strict_exception_groups
is documented as making the exception structure that comes out of a nursery aexit not depend on whether== 1
or> 1
tasks raised, by having a strict nursery always wrap all exception(s) in a new group:but on master this isn't happening:
minimized reproducer 1
expected: the same exception structure with
n = 1
andn > 1
, i.e. two levels of exception groups (or three if the third nursery is uncommented).e.g. with
n = 1
:this is the behavior on v0.22.2.
observed: (w/ trio @ 6c50dc2, CPython 3.11.6.) different exception structure depending on
n = 1
vs.n > 1
.e.g. with
n = 1
:the task's crash is in only one one exception group, even though it occurred two strict nurseries down the stack. (similarly, if you uncomment the extra nursery, it's still only one when it should be three.)
while this new behavior will not break
except*
usage (becauseexcept*
recurses), it is still a problem. for example:minimized reproducer 2
expected: two exception groups, and trio doesn't cause your exception group messages/notes to be hidden:
observed: one exception group, and trio causes some exception group messages/notes to be hidden:
details
i encountered this regression while testing a downstream work against trio master in preparation for the upcoming v0.23 release.
this bisects to #2826 (CC @jakkdl). from its newsfragment, tests, and surrounding discussions, my understanding is that #2826's primary intent was to hide the implementation-detail nursery of
start
(i.e. to resolve #2611)—but that it did not intend to make trio violate itsstrict_exception_groups
docs & also hide third-party exception messages from tracebacks.The text was updated successfully, but these errors were encountered: