This warning fires at garbage-collection time, far away from the code that caused it - usually a coroutine that was never awaited or a resource that was never closed. Turn the warning into an error with a full traceback, then hunt for un-awaited coroutines and unclosed sockets, files, or event loops in the tests that ran just before it.

```text
pytest warning "PytestUnraisableExceptionWarning" failing CI with filterwarnings=error: how to find the source
```

## Steps

1. Reproduce it locally with the warning promoted to an error and full tracebacks on: run pytest with -W error::pytest.PytestUnraisableExceptionWarning and --tb=long so the collection-time context is captured.

   Expected: The warning becomes an error with a traceback instead of a bare warning line.

2. Read the traceback for what was unraisable: the message names the object type, usually a coroutine, a socket, or an event loop. That tells you what kind of leak to hunt.

   Expected: You know the leaked object type, e.g. a coroutine that was never awaited.

3. Narrow the suspect set: run test files one at a time until the warning appears. Then bisect within the file. The culprit is almost always an async test or fixture.

   Expected: You have the single test or fixture that triggers the warning.

4. Search the suspect code for the classic sources: a coroutine created but never awaited, a client session opened without close, a loop or thread left running, or a mock that swallowed an await.

   Expected: You find the exact line that creates the object nobody cleans up.

5. Fix the leak at the source: await the coroutine, close the resource in a fixture finalizer, or cancel the background task. Rerun with the strict warning filter until the suite is clean.

   Expected: The full suite passes with filterwarnings=error and no unraisable warnings.

## Use this when

- CI fails on PytestUnraisableExceptionWarning with no clear location
- a warning about an un-awaited coroutine or unclosed resource
- filterwarnings=error turns a mystery warning into a build failure

## Not for this skill when

- the warning already names the exact file and line (just fix that line)
- the failure is an assertion or an exception in test code
- the warning comes from third-party library internals you cannot change (filter it explicitly)

## Variant phrasings

- PytestUnraisableExceptionWarning how to find source
- PytestUnraisableExceptionWarning failing CI filterwarnings error
- unraisable exception warning no traceback where is it from

## Why it happens

Python reports unraisable exceptions when an object with a failing finalizer gets garbage collected - the error surfaces in the GC, not where the bug lives. The usual suspects are coroutines that were created but never awaited (their never-ran cleanup raises at collection) and network resources nobody closed. Pytest wraps these as PytestUnraisableExceptionWarning, and with filterwarnings=error the build dies on a warning whose location points at the garbage collector instead of your code.

## Edge cases

- Async fixtures are a frequent source: an async generator fixture that never gets its teardown awaited leaks the same way.
- If the warning is intermittent, it depends on GC timing; forcing gc.collect in the test teardown can make it deterministic.
- When the leak is inside a third-party library, add a targeted warning filter for that module rather than weakening the global filter.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_57i2vvORJ8SmBn-1VIkEbQ