Conversation
|
Didn't know it was not supported till now |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
⬆️ Add support for Python 3.13
This has been triggering a hard to debug error on Python 3.13 with Pydantic v1. It only happens there, it only happens the first time the test is run. When I connect to the remote GitHub Actions runner and run it once, it shows the error, when I run it again, it disappears. It only shows up when running the entire test suite, running the exact file where the error normally shows up, passes the test "without errors".
It seems it only happens when running the tests with coverage, as in:
coverage run -m pytest testsBut running pytest directly doesn't show the error.
On that first run, it always shows on the same test, even though it seems it's not completely related to that test.
First it would show up in
tests/test_tutorial/test_websockets/test_tutorial002.py:If I remove that file, then it shows up in another file, in this case in
tests/test_validate_response_recursive/test_validate_response_recursive_pv1.py:The traceback doesn't give much information. I temporarily updated the tests in the file to alter the order of the context managers and then the traceback would point to another line. Not to the internal
weakrefbut to Starlette'sdatastructures.MutableHeaders.__delitem__, in the line with:Showing the error in
enumerate(self._list). But that doesn't make much sense.Using a context manager for the
TestClientwould then show the traceback somewhere at Starlette's middleware.Then changing it more would show the traceback in coverage's
should_start_context_test_function.The current theory is that coverage stores data in SQLite files and some of its internal parts are at some point not closing a DB. I would imagine that's not shown in the traceback maybe because of the ways it injects its logic into the executing runtime Python.
As this seems to be a corner case only related to the testing setup with coverage, the current workaround is just a warning filter in the config.