-
-
Notifications
You must be signed in to change notification settings - Fork 339
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Recover from a 'foreign await' by throwing in the TypeError #1178
Conversation
This improves debuggability (since the traceback points to the location of the error, rather than just the nursery whose task was at fault) and fixes python-trio#552 by ensuring we don't abandon the child tasks of the errant one.
Nice!
|
Codecov Report
@@ Coverage Diff @@
## master #1178 +/- ##
==========================================
+ Coverage 99.56% 99.57% +<.01%
==========================================
Files 106 106
Lines 12776 12800 +24
Branches 981 983 +2
==========================================
+ Hits 12721 12745 +24
Misses 35 35
Partials 20 20
|
Added the requested test. I don't think having send() written in C is a fundamental invariant; what in your model would require that? A Python implementation will add an extraneous traceback frame at each task boundary, but that seems like a reasonable accounting of what really happened. I tried running Trio's testsuite with |
(Not sure what codecov is on about -- it looks green on the website.) |
Codecov is complaining that this line is "partially" covered: assert any(entry.name == "child_xyzzy" for entry in excinfo.traceback) I guess it's something to do with the embedded loop – maybe because it always exits early?
I guess I had two things in mind:
|
This early exit is totally uninteresting, no reason for coverage to hassle us over it.
This improves debuggability (since the traceback points to the location of the error, rather than just the nursery whose task was at fault) and fixes #552 by ensuring we don't abandon the child tasks of the errant one.