bug: `ydb.aio.retry_operation` retains memory on exceptions chained from Pydantic validation errors
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
Start at the ydb.aio.retry_operation entry point and build the reported Python 3.12/Pydantic 2.13.4 reproduction, comparing it with directly awaiting the coroutine. Trace the retry result, application exception, ValidationError, traceback, and coroutine references; done means otherwise-unreferenced locals are collectible after handling the exception and running gc.collect().
由索引模型根据 Issue 内容生成。
描述
Bug Report
Coroutine-local objects remain alive after ydb.aio.retry_operation propagates an application exception chained from a Pydantic ValidationError, even after the caller handles the exception and explicitly runs gc.collect(). No database connection is required to reproduce this.
YDB Python SDK version:
version 3.31.4
Environment
Environment: Python 3.12, Pydantic 2.13.4, pydantic-core 2.46.4.
Current behavior:
- Directly awaiting the same coroutine releases its local objects.
- Calling it through
ydb.aio.retry_operationretains them. - A simple application exception without the validation-error cause did not reproduce the retention.
The observed reference chain is:
YdbRetryOperationFinalResult
→ application exception
→ Pydantic ValidationError
→ traceback
→ coroutine frame and local objects
Possible Pydantic-specific interaction: the reproduction uses a union of custom validators that raise ValueError. Pydantic can retain these underlying exceptions as validation-error context, potentially adding traceback references to the retry-state cycle. Its native implementation may be relevant to why the objects survive garbage collection, but this mechanism has not been established.
Expected behavior:
Once the operation has failed and the caller has handled the exception, otherwise-unreferenced coroutine locals should be collectible.
Steps to reproduce:
- Create a coroutine that allocates a local object and triggers a Pydantic validation error using a union of failing custom validators.
- Raise an application exception chained from that ValidationError.
- Compare directly awaiting the coroutine with calling it through ydb.aio.retry_operation.
- Handle the exception, run garbage collection, and check the local object through a weak reference.
- In the tested reproduction, the direct call released the object, while the SDK retry call retained it.
- 主要语言
- Python
- 星标
- 102
- 派生
- 77
- 平均合并
- 2 天 17 小时
- 30 天内合并 PR
- 11
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
ydb-platform/ydb-python-sdk 的其他 Issue
-
enhancement
难度 2/5 1-3 小时 新手友好度 62/100
ydb-platform/ydb-python-sdk#290 ·
维护者通常 1 天内回复
-
enhancement
难度 4/5 3-5 天 新手友好度 45/100
ydb-platform/ydb-python-sdk#897 ·
维护者通常 1 天内回复
-
dev: improve codebase documentation可能已有人在做 @Khabib73 于 21 天前认领。 未关闭enhancement
ydb-platform/ydb-python-sdk#895 · 1 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
-
enhancement
难度 3/5 1-2 天 新手友好度 55/100
ydb-platform/ydb-python-sdk#884 · 1 条评论 ·
维护者通常 1 天内回复
-
enhancement
难度 5/5 一周以上 新手友好度 35/100
ydb-platform/ydb-python-sdk#876 ·
维护者通常 1 天内回复
查看 ydb-platform/ydb-python-sdk 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 78/100
conda-forge/conda-build-feedstock#289 · 1 条评论 · 1 个 reaction ·
-
`pulptest` no longer works in 4.0.0: `ImportError: Start directory is not importable: 'pulp/tests'`未关闭
难度 2/5 1-3 小时 新手友好度 75/100
-
难度 2/5 1-3 小时 新手友好度 72/100
-
难度 2/5 1-3 小时 新手友好度 78/100
-
难度 2/5 1-3 小时 新手友好度 72/100
TomCasavant/ohio-sites#224 ·