如何解决PyMongo事务中的SessionNotFound

SessionNotFound 错误源于事务已结束或未正确开启，非网络或服务端配置问题，而是客户端 session 失效：已调用 end_session() 后复用，或 start_transaction() 未成功；即使 has_ended 返回 False，服务端超时终止后 session 仍无效。

SessionNotFound 错误只发生在事务已结束或未正确开启时

这个错误不是网络问题，也不是 MongoDB 服务端配置问题，而是 PyMongo 客户端明确告诉你：session 对象已失效或从未被激活。常见于两种情况：一是 session.end_session() 已调用，后续还试图用它执行操作；二是 session.start_transaction() 根本没成功（比如事务已被服务端中止，但客户端没捕获异常就继续用了）。

为什么 session.has_ended 返回 False 却仍报 SessionNotFound

session.has_ended 只反映是否显式调用了 end_session()，不表示该 session 是否仍被服务端认可。一旦事务因空闲超时（transactionLifetimeLimitSeconds 默认 60 秒）被服务端强制终止，客户端的 session 对象依然“活着”，但再传给任何操作都会触发 SessionNotFound。

1. 事务内耗时操作（如外部 HTTP 请求、复杂计算）超过 60 秒，服务端已 kill 事务，但代码没检查就继续 commit_transaction()
2. 事务抛出异常后只 abort_transaction()，却忘了 end_session()，下次复用该 session 就会失败
3. 在 finally 块里调用了 end_session()，但之前已发生异常导致 session 实际不可用，此时再用它做任何事都无效

如何避免 SessionNotFound 的实操要点

核心原则：每个 session 只能用一次，且必须确保事务生命周期可控。

1. 不要复用 session 对象——每次事务都用 client.start_session() 新建
2. 事务块必须用 try/except/finally 包裹，finally 中只做 session.end_session()，绝不在此之后再调用 commit_transaction() 或 abort_transaction()
3. 对长耗时操作，提前拆分事务，或用 max_commit_time_ms 控制 commit 阶段耗时（注意它不延长事务存活时间）
4. 若需重试，必须新建 session，不能沿用旧的——PyMongo 的 ClientSession 不支持重连或恢复

SessionNotFound 和 StaleConfigError 容易混淆，但根源完全不同

StaleConfigError 是副本集配置变更导致 session 失效，而 SessionNotFound 是事务上下文彻底丢失。前者可换新 session 重试，后者说明你正在操作一个早已被服务端丢弃的会话 ID。

真正容易被忽略的是：事务空闲超时是服务端单向行为，客户端无回调通知。你无法靠 session.in_transaction 判断它是否还有效——这个属性只反映客户端本地状态，不与服务端同步。