aio-libs / aio-libs/aiocache

Potential memory leak/bug in the valkey client

未關閉
#1,023 1 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視
主要語言
Python
星號
1.4k
分支
181
PR 合併指標
30 天內沒有已合併 PR

描述

I think there might be an issue with the `__aenter__` method on the ValkeyBackend.
https://github.com/aio-libs/aiocache/blob/d685fff3303138eb466a69bb5dbb4d6a345ef1ae/aiocache/backends/valkey.py#L32-L37

This code snippet explains my thinking.
```
async def cache_operations():
client_1 = None
async with ValkeyCache(
config=GlideClientConfiguration(addresses=[NodeAddress("localhost", 6379)])
) as my_cache_1: # <<< new client created
client_1 = my_cache_1.client
async with my_cache_1 as my_cache_2: # <<< new client created
assert my_cache_1 is my_cache_2 # because of return self
client_2 = my_cache_2
assert client_1 != client_2
assert my_cache_1.client == client_2
# exit inner with, call __aexit__, calls await self.client.close(); i.e. client_2.close())
assert my_cache_1.client != client_1 # it's still client_2
# exit inner with, call __aexit__, calls await self.client.close(); i.e. client_2.close() again, which may error.
# client_1.close() may never be called
```
I think that the `__aenter__` method should maybe handle checking if an existing connection is available and disposing of it if not, or else return a clone of `self` with a new client to ensure that the connection does get managed correctly.

貢獻指南

開啟貢獻指南

評估

這個 Issue 還沒有評估資料。

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。