Skip to content

special handling for unawaited coroutine warnings #86

Open
@njsmith

Description

@njsmith

In chat today, @catern was talking about how they got burned badly by forgetting an await, and was planning to make their test suite capture these warnings and fail any test that issued them. (For more background on why this is a difficult situation to handle well, see python-trio/trio#79).

Maybe pytest-trio should do this by default, on a best-effort basis? Pytest is already capturing warnings and attaching them to each test's output. There are some limitations:

  1. Sometimes the unawaited coroutine warning shows up later; possibly in a different, unrelated test. We could reduce the chances of this by invoking the GC after each test. Maybe we don't want to invoke the GC after every single test we run, though? It might slow things down. How much? I guess the worst case would be test suites with lots and lots of tests, to make the live set as made as possible? (Would it make sense to use different policies on CPython and PyPy?)

  2. Pytest gives a lot of options for configuring its warning capture, or disabling it altogether. We can't go breaking this. So maybe we'd just need to be careful to gracefully disable this feature whenever pytest's warning capture is in a non-default mode?

  3. In many cases, a test will crash and the root cause will be a missing await, but the proximal cause is something else and the resulting error is super confusing. In these cases, it would be nice if this feature could help users pinpoint the root cause. But this is tricky, because:

  • sometimes you don't get a warning in these cases, because the crash traceback captures the test's stack frames, so the coroutine __del__ doesn't run, so it doesn't issue the warning.

  • sometimes you do get a warning, but this is just a symptom, not the root cause. In particular, this tends to happen for certain kinds of violations of Trio's internal invariants that cause the scheduler to error out. Maybe a simple heuristic would be good enough though, like: if the test crashed with TrioInternalError, then don't worry about unawaited coroutines?

Again, this would be a best effort feature, so we don't have to solve all these problems perfectly from the start.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions