跟踪 Python 3.14 测试中偶发的 aiosqlite event-loop 关闭警告

[liujuanjuan1984]

背景

在 #515 的 SDK 兼容审计期间，全量 ./scripts/doctor.sh 偶发出现 PytestUnhandledThreadExceptionWarning：aiosqlite 的 _connection_worker_thread 尝试通过 call_soon_threadsafe 回调时，pytest event loop 已关闭。

该警告在锁定的 a2a-sdk 1.1.2 与临时安装的上游 v1.1.3 release commit 环境中都观察到，因此不是 SDK 升级或 #514 出站鉴权修改引入。测试本身仍通过。

当前证据

• 环境：Python 3.14.6、aiosqlite 0.22.1。
• 曾在 tests/server/test_transport_contract.py 测试执行附近出现。
• 单独以 -W error::pytest.PytestUnhandledThreadExceptionWarning 重跑相关测试未复现，初步判断为 teardown/lifecycle 时序问题。

建议调查

• 检查 app/database engine fixture 是否等待所有 aiosqlite worker 与 connection 完整关闭。
• 在 Python 3.14 下重复运行 database/transport tests，形成稳定复现。
• 判断是否需要将该 warning 提升为 CI error，避免资源泄漏被测试成功状态掩盖。

验收标准

• 获得稳定复现或确认触发条件
• 明确是测试 fixture、应用生命周期还是 aiosqlite 上游问题
• 修复后在 Python 3.14 重复运行不再出现该 warning
• ./scripts/doctor.sh 通过

[liujuanjuan1984]

已基于最新 main（a350a80，包含已合并的 #514）创建独立 worktree 与分支 investigate/516-aiosqlite-thread-warning，开始复现和生命周期审计。将重点确认是否存在未关闭的 AsyncEngine/aiosqlite connection、pytest event loop teardown 竞态或 Python 3.14/aiosqlite 上游行为差异；在确认资源是否真实泄漏前，不会把该 warning 简单忽略。

[liujuanjuan1984]

已基于最新 main（a350a804d03eab9d58b38c2bb154b091a80c2380）在独立 worktree 完成复现、定位和候选方案验证。

结论

该警告不能作为无害噪声放任或全局忽略。它由真实的 aiosqlite.Connection 未关闭引起：连接被 GC 回收时，worker thread 仍尝试向已经关闭的 event loop 投递结果，于是警告常延迟出现在后续测试，表面上才显得“偶发”。

在 Python 3.14.6、aiosqlite 0.22.1、SQLAlchemy 2.0.52 的锁定环境中，将 ResourceWarning / PytestUnhandledThreadExceptionWarning 提升为错误后可以稳定复现。

根因

1. 生产代码异常路径：SQLite 文件加固检查当前在 SQLAlchemy connect listener 中执行。此时底层 aiosqlite 连接及 worker thread 已创建；若检查因数据库路径被换成 symlink 而抛错，SQLAlchemy 当前连接流程不会关闭这个尚未完成接管的 DBAPI 连接。
2. 测试清理问题：以下三个测试把 engine 类型的 dispose() 替换为 AsyncMock 来验证共享 engine 不会被 runtime 释放，但测试结束时也没有调用预先保存的真实 dispose()，因此测试自己留下了连接：
   • test_build_task_store_does_not_dispose_shared_engine
   • test_build_task_store_runtime_does_not_dispose_shared_engine
   • test_build_runtime_state_runtime_initializes_and_preserves_shared_engine

建议方案

1. 将 SQLite 路径加固复检移动到 SQLAlchemy 官方 do_connect 事件，在物理 DBAPI 连接创建前拒绝 symlink，避免先创建资源再失败，也避免打开不受信任的目标。
2. connect listener 仅负责 PRAGMA；同时增加异常兜底：配置失败时显式关闭刚创建的 DBAPI 连接后再原样抛出，覆盖游标或 PRAGMA 配置失败等其他路径。
3. 三个 ownership 测试在 monkeypatch 前保存真实 engine.dispose，并在 finally 中调用；仍保留 spy 断言，以同时验证“不由 runtime 释放”和“测试最终清理”。
4. 回归测试应断言 symlink 复检失败不会创建第二个 aiosqlite 连接，并断言已创建连接最终均关闭。不要添加 warning ignore；可考虑在测试配置中把 unraisable/thread/resource 类警告升级为错误，令同类泄漏尽早暴露。

候选实现验证

诊断期间临时实现上述方案并加入连接追踪：

• 相关 102 项测试：全部通过，创建 48 个连接、未关闭 0 个；
• 完整测试：819 passed, 4 warnings，创建 92 个连接、未关闭 0 个；剩余 4 条为已知 SDK EventQueue deprecation warning，与本 issue 无关；
• 变更文件的 Ruff 及 database.py 的 mypy 均通过。

诊断改动现已撤回，评估 worktree 保持干净，尚未提交实现。建议按上述方案直接进入 #516 开发。SQLAlchemy 最新稳定版及当前主干的连接流程仍存在 listener 抛错时不主动清理该连接的行为；后续可以友善提交上游 issue，但本仓库无需等待上游，可通过更合适的 pre-connect hook 和本地异常清理先完整修复。

[liujuanjuan1984]

#516 的实现已提交至 Draft PR #517，并完成两轮独立审查与查改。

最终方案包括：连接前安全预检、连接后纵深复检、初始化异常时显式关闭 DBAPI 连接、三个共享 engine 测试的真实资源清理，以及针对未处理线程/析构异常的 pytest 门禁。

审查中特别验证了不能把 aiosqlite 的 ResourceWarning 直接设为 error：这会在其 __del__() 中提前抛出并阻断 worker stop()。最终策略是强制展示该精确警告，同时把 PytestUnhandledThreadExceptionWarning 和 PytestUnraisableExceptionWarning 设为 error。

最终 ./scripts/doctor.sh：821 passed，覆盖率 93.35%，完整质量、构建及 wheel smoke test 均通过。当前没有已知未收敛问题。