-
-
Notifications
You must be signed in to change notification settings - Fork 3k
Description
- a detailed description of the bug or problem you are having
-
output of(N/A, design bug)pip listfrom the virtual environment you are using -
pytest and operating system versions(N/A, design bug) - minimal example if possible
I had a baffling case where a caplog filter set up by a yield fixture with caplog.filtering was gone by the time the test case using the fixture was executed. I eventually traced the problem down to a separate non-yielding fixture that used caplog.filtering with the same filtering function around an immediate setup operation.
The issue is that the standard library's addFilter/removeFilter log handler methods work by value, so
Line 579 in 3c37b55
| def filtering(self, filter_: logging.Filter) -> Generator[None]: |
Minimal example:
def test_caplog_fixture(caplog):
import logging
def no_capture_filter(log_record):
return False
with caplog.filtering(no_capture_filter):
logging.warning("Will not be captured")
with caplog.filtering(no_capture_filter):
logging.warning("Will also not be captured")
logging.warning("Will incorrectly be captured")
assert caplog.records == [] # FailsThere are two ways I see to allow nested invocations to work without side effects:
- add an external check to see if the given filter is already in
self.handler.filtersand skip the add/remove pair entirely in that case (it's unfortunate thataddFilterdoesn't return a boolean value to indicate if the filter list changed or not); or - save a full snapshot of the filter list before calling
addFilterand restore that instead of usingremoveFilter
The former is presumably the better option, since it's just an extra scan of the filter list rather than making two full copies of the list (one to take the snapshot, one to insert the snapshot back into the original filter list).