> On 30 Oct 2020, at 13:56, Adam Johnson <m...@adamj.eu> wrote: > > > I'd be making sure we cleaned that up before merge (or, can you filter > > those... — I guess you can 🤔) > > In my experience I’d something doesn’t fail, it gets ignored. Few people read > the logs of passing test runs and most projects I’ve seen have a pile of > noisy warnings making detecting unraisable exceptions even more unreasonable. > > In the asyncio case, an unraisable exception could indeed represent bad test > code, but it could also reveal a bug in the production code which no test > assertion would (or even could?) pick up.
Not sure… In my experience of these it’s normally that the test case exited (having passed) before the asyncio task (being run in another thread) fully exited. So you end up putting a (e.g.) communicator.wait() in to clean it up. Not saying that shouldn’t be there, but these things can be so hard to write at all that to fail on that might be setting the bar too high. (You want to see green — yes, my test worked.) You’re right that these can linger, but not with Mariusz on the case :) These errors though are raised at process exit thought right? (i.e. aren’t they after the test suite already reported as passed/failed?) 🤔 Kind Regards, Carlton -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5B0EA3FD-CC0D-446E-BACC-3ACDEFEB2682%40gmail.com.
