Comments (7)
This isn't really an issue with aiohttp, it's an issue with your architecture/coding practices.
If you always use async with
when creating a session, then you won't have any unclosed sessions. Alternatively, I've seen libraries that provide context manager stacks as part of an application's lifecycle (maybe combined with dependency injection). You can use a linting rule or something to enforce this usage across your code.
from aiohttp.
Thanks for your prompt reply.
While I know that async with
is the recommended pratice, there are situations where we might be called upon to debug code outside of our control, such as code written by others or in third party modules. (aiohttps is used by many third party aio modules).
Unfortunately, when these external sources don't use async with
, it can be challenging to identify the unclosed sessions.
Only after pingpointing these unclose sessions, can we suggest adpoting async with
as a best pratice.
So I think this is real use case.
from aiohttp.
Hmm, the issue is much the same as any other asyncio primitive, so we should probably do the same as asyncio does or suggest similar changes there.
The only thing I can think of is to get the current traceback when the object is initialised and then include that in the warning. This would probably need to be done only when using debug mode to avoid the overhead.
from aiohttp.
If you want to give it a go, it'd probably look something like:
from aiohttp.helpers import DEBUG
if DEBUG:
self._tb = traceback.extract_stack()
from aiohttp.
hello,
Do you mean save the traceback stack during the session __init__
if DEBUG mode is on, and display it in the error message as follows ?
Like:
class ClientSession:
def __init__(
self,
...
) -> None:
+ if DEBUG:
+ import traceback
+ self._tb = traceback.extract_stack()
...
def __del__(self, _warnings: Any = warnings) -> None:
if not self.closed:
kwargs = {"source": self}
_warnings.warn(
f"Unclosed client session {self!r}", ResourceWarning, **kwargs
)
message = "Unclosed client session"
+ if DEBUG:
+ message += f"\nSession creation traceback stack: {self._tb}"
context = {"client_session": self, "message": message}
if self._source_traceback is not None:
context["source_traceback"] = self._source_traceback
self._loop.call_exception_handler(context)
from aiohttp.
That was my suggestion, yes. Feel free to make a PR if you've got it working. Will need a test to show it's working correctly too (needs to be marked with @pytest.mark.dev_mode
).
from aiohttp.
sorry, I just found it's already been implemented, when setting the env var PYTHONASYNCIODEBUG=1
, the unclosed session gives already the creation traceback, all is good now, thank for your help.
from aiohttp.
Related Issues (20)
- The `timeout` parameter of `aiohttp.ClientSession` does work for types other than `Union[ClientTimeout, _SENTINEL, None]` HOT 5
- Analyze additional places where there is timer handle churn HOT 7
- Risk of websocket ping tasks being garbage collected before they finish HOT 1
- Remove wait_for_disconnection
- Remove `allowed_protocol_schema_set` backwards compat in `BaseConnector` HOT 1
- Multipart reader fails on Transfer-Encoding: chunked HOT 9
- pytest example in testing.rst throws TypeError: 'async_generator' object is not callable HOT 2
- Response object reference to session returns None HOT 2
- ClientResponse.json() doesn't set status code HOT 3
- [typing] mypy errors when trying to extract headers when type is `LooseHeaders` HOT 1
- Support free-threaded Python 3.13 build HOT 2
- TypeError: _patch_task.<locals>.task_new_init() got an unexpected keyword argument 'eager_start' HOT 5
- Sending default 'Server' header when failing on wrong HTTP method HOT 6
- Websocket ping test has transient failures on loaded systems HOT 1
- Send 100-continue only when handler reads body
- typing error with `timeout` argument of `aiohttp.ClientSession` requests methods HOT 1
- Rename compress parameter HOT 6
- on_request_headers_sent params type was never imported into the top-level file. HOT 2
- AsyncResolver not passing on loop too aiodns.DNSResolver HOT 4
- test_web_sendfile_functional isn't testing sendfile
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from aiohttp.