Pydantic AI 修复并发限流器槽位泄漏
先了解这件事
Pydantic AI 的 ConcurrencyLimitedModel 及 limit_model_concurrency 存在并发槽位泄漏问题:流式请求可能在与获取槽位不同的任务上释放槽位,被 anyio.CapacityLimiter 拒绝,导致槽位在请求结束后仍被占用。流提前结束或按默认 debounce_by=0.1 完整消费 stream_text() 都可能触发,若对外暴露受影响的流式接口并在请求间共享长期存活的限流器,影响会进一步放大。Pydantic AI 在 v2.53.0 中修复了这一高危安全问题(GHSA-6fqq-452j-qhrp),涉及消费者提前停止迭代、抛错或被取消之后,以及用默认 debouncing 完整消费 stream_text() 的场景。
AI 根据报道生成 · 3 天前更新
后续时间线
- Pydantic AIPydantic AI v2.53.0 修复 ConcurrencyLimitedModel 并发槽位泄漏漏洞
Pydantic AI 在 v2.53.0 中修复了 ConcurrencyLimitedModel 的一个高危安全问题(GHSA-6fqq-452j-qhrp):通过 ConcurrencyLimitedModel 或 limit_model_concurrency 发起的流式请求,可能在槽位由不同任务释放时仍占用并发槽,包括消费者提前停止迭代、抛错或被取消之后,以及用默认 debouncing 完整消费 stream_text() 之后;反复发起这类流可能阻塞共享同一限流器的所有请求。Agent 级别的 max_concurrency 和非流式请求不受影响,v1 不受影响,该问题由 @lche511 报告。
- GitHub 安全公告Pydantic AI 并发限流模型在流式请求提前结束时会永久占用槽位
Pydantic AI 的 ConcurrencyLimitedModel 及 limit_model_concurrency 存在并发槽位泄漏问题:流式请求可能在与获取槽位不同的任务上释放槽位,被 anyio.CapacityLimiter 拒绝,导致槽位在请求结束后仍被占用。流提前结束或按默认 debounce_by=0.1 完整消费 stream_text() 都可能触发。若对外暴露受影响的流式接口并在请求间共享长期存活的限流器,客户端反复发起流并断开即可耗尽并发容量,使后续请求无法进行;清理过程还可能抛出 RuntimeError。Agent 级 max_concurrency 和非流式模型请求不受影响。缓解方式是升级到修复版本,或改用 Agent 级 max_concurrency、避免让流式运行经过并发限流模型。
相关讨论
关注度走势
每天新增来源
- 10月2日新增1个来源(1家媒体、0个账号)
- 10月3日新增0个来源(0家媒体、0个账号)
- 10月4日新增0个来源(0家媒体、0个账号)
- 10月5日新增0个来源(0家媒体、0个账号)
- 10月6日新增0个来源(0家媒体、0个账号)
- 10月7日新增0个来源(0家媒体、0个账号)
- 10月8日新增0个来源(0家媒体、0个账号)
- 10月9日新增1个来源(1家媒体、0个账号)
- 10月10日新增0个来源(0家媒体、0个账号)
- 10月11日新增0个来源(0家媒体、0个账号)
- 10月12日新增0个来源(0家媒体、0个账号)