Add creation tracebacks to unclosed warnings#12691
Conversation
psf-chronographer
Bot
added
the
bot:chronographer:provided
for more information, see https://pre-commit.ci
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #12691 +/- ##
=======================================
Coverage 98.95% 98.95%
=======================================
Files 131 131
Lines 46688 46697 +9
Branches 2421 2422 +1
=======================================
+ Hits 46200 46209 +9
Misses 366 366
Partials 122 122
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Merging this PR will not alter performance
Comparing 
Footnotes
|
| gc.collect() | ||
|
|
||
| warning_message = str(cm[0].message) | ||
| assert "The object was created at" in warning_message |
There was a problem hiding this comment.
Can we extend these tests to verify the trackback is correct? e.g. that session = ClientSession(connector=connector) is in the traceback.
2 participants
What do these changes do?
Include the object creation traceback in unclosed resource warning messages when the event loop is running in debug mode.
Are there changes in behavior for the user?
Yes. In debug mode, unclosed
ClientSession, connection, connector, and response warnings now include where the object was created, making leaks easier to trace. Non-debug behavior is unchanged.Is it a substantial burden for the maintainers to support this?
No. This reuses the existing
_source_tracebackcaptured in debug mode and keeps the formatting in a small helper shared by the existing unclosed-resource warnings.Related issue number
Fixes #11235.
Checklist
CONTRIBUTORS.txtCHANGES/foldername it
<issue_or_pr_num>.<type>.rst(e.g.588.bugfix.rst)if you don't have an issue number, change it to the pull request
number after creating the PR
.bugfix: A bug fix for something the maintainers deemed animproper undesired behavior that got corrected to match
pre-agreed expectations.
.feature: A new behavior, public APIs. That sort of stuff..deprecation: A declaration of future API removals and breakingchanges in behavior.
.breaking: When something public is removed in a breaking way.Could be deprecated in an earlier release.
.doc: Notable updates to the documentation structure or buildprocess.
.packaging: Notes for downstreams about unobvious side effectsand tooling. Changes in the test invocation considerations and
runtime assumptions.
.contrib: Stuff that affects the contributor experience. e.g.Running tests, building the docs, setting up the development
environment.
.misc: Changes that are hard to assign to any of the abovecategories.
Use the past tense or the present tense a non-imperative mood,
referring to what's changed compared to the last released version
of this project.