[jinghero]

摘要

• Windows 上关闭网络连接报错后，仍释放连接并完成收尾，避免退出卡住。
• 保留 10022 原始错误，补充脱敏的连接来源分类，沿用现有 Sentry 开关与过滤。
• 新增连接关闭故障、重复收尾和诊断隐私的回归验证。

关联 Sentry AUTO-MAS-BACKEND-2V。

验证

Windows、CPython 3.12.13，提交 09b33fa239a5dc2531e260daf12b18808f3f54cb。

• 同一条 10022 回归在关闭兼容入口时失败，socket 仍打开；启用后通过，服务端关闭等待正常结束。
• uv run --no-sync python -m pytest tests/utils/test_asyncio_compat.py tests/test_main.py tests/core/test_ws_connection.py -q：18 passed，15 subtests passed。
• uv run --no-sync ruff format --check .、改动文件的 Ruff 检查、兼容模块的 mypy 检查、三平台 mypy 契约、uv lock --check 和更新日志检查通过。
• yarn e2e:check 通过；yarn e2e --grep '@smoke'：1 passed。测试进程移除了本机的 Sentry 上传凭据，不发送验证事件。
• 全量 CI：Windows 2019 passed、1 skipped；Ubuntu 1976 passed、43 skipped；两侧均另有 17 subtests passed，三平台 mypy 契约全部通过。格式、依赖、更新日志及 Windows 验证包检查全部通过。
• 本机全量回归在 MaaEnd 更新测试的 asyncio 线程池退出阶段停住，同一用例在未修改的上游基线 05e671babd38d17201bdab6c378ac476f1513c3e 上也停在同一位置，因此未计为本机通过；以上全量结果来自 CI。

边界

兼容实现依赖当前锁定的 Python 3.12 Proactor 私有接口，升级 Python 时需重新核对并在上游覆盖后移除。诊断仅包含服务端/客户端、协议分类、TLS、地址族及是否回环，不记录地址、端口、请求、路径或对象内容。验证覆盖已观测错误的注入及后续清理，尚未复现 10022 的原始网络触发条件。

[chatgpt-codex-connector]

Codex Review Summary: ✅ Completed

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-11-13T04:00:05.148583Z	09b33fa	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[jinghero]

总体结论：可以合并

AUTO-MAS-Project/AUTO-MAS #1967

这次补的是“报错后也要把连接收完”，不是把 10022 藏起来，方向对啦。dot酱对照了项目锁定的 CPython 3.12.13：原实现的 shutdown() 一旦抛错，确实会跳过 socket 关闭和服务器连接计数释放，让等待关闭的流程一直等下去。审查范围内没有确认的必须修改项。

兼容入口仍按“通知协议 → shutdown → close → 释放服务器计数”的顺序执行，只把后续清理放进 finally；原异常继续上报，重复回调不会重复扣计数。安装由启动入口负责，非 Windows 不修改实现，业务模块也不用各自补一遍。既然依赖了标准库私有接口，保留当前写明的 Python 升级复核和上游修复后移除条件就很重要喵。

诊断也收得克制：只附加服务端/客户端、协议类别、TLS、地址族和回环分类，不带地址、端口或对象内容；继续走现有 Sentry 开关与过滤，没有另开上报通道。测试用真实 socket、transport 和服务器等待逻辑，在关闭边界注入故障，还检查了重复收尾和脱敏序列化，比单纯断言 close() 被调用更能守住这条清理链。

本次主审及两个独立视角均为静态检查，没有独立运行项目或测试。已读取 CI 全量日志：Windows 2019 通过、1 跳过，Ubuntu 1976 通过、43 跳过，两边各有 17 个子测试通过。这里能确认的是故障后的资源清理；现场 10022 的原始触发条件仍未查明，不把故障注入说成真实网络复现啦。

—— dot酱敬上 🐾