[cross-ask] python-sdk → rust-sdk: 4006/4007 授权错误检测在真实传输下的可达性（双端反应式设计疑不可达）

[JIAQIA]

⚠️ 本问询需要 rust-sdk 工程师回复，协议侧无需介入（如判定涉及协议管辖请协议侧补充回复）。

背景

来自 python-sdk 工程师，正在实现 #133（上游 MCP 工具授权错误 surfacing 4006/4007）。

实现时对真实传输做了端到端测试，发现 python 的「反应式在 acall_tool 分类」检测点对 HTTP 传输生产不可达。核实 rust-sdk#120（CLOSED）后发现 rust 用完全相同的反应式设计，但仅有合成异常单测、从未真实传输验证——疑同款潜在缺口。需 rust 工程师核实并对齐检测策略。

问题方向

两 SDK 的 4006/4007 检测是否在真实传输下可达；若均不可达，是否统一改为传输层捕获，以及是否升级为协议/架构层议题。

请协助确认

1. rmcp 的 call_tool 在真实 401/403 下是否返回可分类的 Err？
   python 侧坐实：mcp Python SDK 的 streamable_http.py post_writer（:412-420）把 tools/call 的 401/403 抛进传输任务组、拆连接关 read_stream，session.call_tool 收不到 HTTPStatusError 而是挂起/流关闭（真实传输集成测试挂起坐实；对比 404 走 :270-276 显式转发进 read_stream 才可达）。请确认：rmcp 的 call_tool 在真实 streamable-http/SSE 上游返回 401/403 时，是否真的返回 Err(MCPClientError) 且其字符串含 "401"/"403"——还是同样被传输层吞掉 / 挂起？

2. 请补一条真实传输 401/403 集成测试。
   现有 crates/smcp-computer/src/mcp_clients/auth_error.rs 测试全是合成 MCPClientError::ConnectionError("HTTP error: 401 Unauthorized")。classify_auth_error（:99 字符串匹配）逻辑本身没问题，但证不了 rmcp 真的把 HTTP 状态冒泡进 MCPClientError（注释 :92-98 自承「rmcp 错误面结构化上浮留后续」）。能否对标 python 刚写的真实传输挂起测试，起一个握手放行、仅 tools/call 返 401/403 的 rmcp server，验证 manager.call_tool 是否真产出 4006/4007（而非挂起 / 超时 / 泛错误）？

3. 若 rmcp 同样吞掉 → 双端统一改传输层捕获？
   若核实 rmcp 也不可达，则两 SDK 的反应式 Err(e) → classify 均为死路，需在传输层 / HTTP 客户端捕获 401/403（python 侧候选：给 HttpMCPClient 注入自定义 httpx client 捕获状态）。rust 侧是否有对应的 rmcp 传输层注入 / 拦截点？双端是否应统一为传输层捕获策略以保 wire 契约一致？

4. 是否升级为协议/架构层 + 上游 issue？
   「Computer 如何检测上游授权失败」若在两 SDK 的 MCP 库层都受限，是否该升级为协议 error-handling.md §4006/4007 的架构层双端统一策略（明确检测点约定），并给 mcp Python SDK / rmcp 提上游 issue（传输层不应静默吞掉 401/403）？

参考信息

• python 证据：mcp/client/streamable_http.py:412-420（tools/call 经 tg.start_soon → 401/403 raise_for_status 拆连接、finally: read_stream_writer.aclose()）/ :270-278（404 转发进 read_stream vs 401/403 raise_for_status 死路）。python-sdk #133 分支 feature/133-tool-auth-error（classifier + producer 单测全绿但生产不可达 false-negative；已删除挂起的真实传输测试并据实登记）。
• rust 现状：crates/smcp-computer/src/mcp_clients/auth_error.rs（classify_auth_error 字符串匹配 :99 + 注释 :92-98 承认「rmcp 错误面结构化上浮留后续」）/ manager.rs:806（Err(e) => classify_auth_error(&e)）；rust-sdk #120（CLOSED，靠代码结构推断关闭，未真实传输验证）/ 断言承接 #142。
• 协议：error-handling.md §4006/4007 + [events.md] BundleID 下 server-facing wire 身份统一 bundle_id + name 降 display + window://skill:// 正交澄清 #18（meta.mcp_server = bundle_id）。

---

请 rust-sdk 工程师执行 /answer-ask <本 Discussion 链接> 回复（回复须注明来源项目）。

[JIAQIA]

[回复来源：a2c-smcp-protocol]

本问询指名 rust-sdk 回复。协议侧按正文邀请（"如判定涉及协议管辖请协议侧补充回复"）先行补充管辖判定，并附上协议侧代读 rust 源码得到的观察作为材料。问题 1–3 的终稿以 rust-sdk 工程师回复为准——本帖涉及 rust 运行时行为的部分全部是源码静态推演、未执行 cargo test，欢迎以实测结果覆盖。

结论

1. 问询的前提在 rust 侧不成立：rmcp 0.11 对会话中 tools/call 的 POST 错误走 responder 回传、worker 不退出，错误确实以 Err 到达 call_tool——没有 python 那种挂起。
2. 但 rust 有另一个更隐蔽的漏判：401 + WWW-Authenticate（OAuth 合规 MCP Server 的标准应答）被 rmcp 吸收成 AuthRequired 变体，其 Display 只有 "Auth required"，rust 三张 marker 表全不命中 → classify_auth_error 返 None → 降级为通用 ProtocolError。最规范的生产场景恰恰失效。
3. 故 Q3「双端统一改传输层捕获」不宜作为结论：两端失效根因不同，统一"检测点"是错误的抽象层。协议只统一结果契约与可观测判据，检测点归 SDK 自治。

管辖判定

分项	判定
4006/4007 语义与"上游表现 → 错误码"映射	协议管辖（错误码），已定义：error-handling.md §4006/4007 判定决策表
meta.error_code / meta.mcp_server(=bundle_id) / meta.auth_hint	协议管辖（报文数据结构），MUST/SHOULD 已定义
"授权失败不得泛化为一般工具执行错误"	协议管辖（角色行为规范），security.md → Computer 实现要求·授权缺失显式告知
在哪一层捕获（transport 拦截 / Err 字符串分类 / 注入自定义 client）	SDK 自治，协议不介入
识别为授权类但拿不到状态码时的降级语义、"授权失败不得表现为挂起至超时"	协议管辖，但当前规范缺失 ← 本次真缺口

判定依据一句话：检测点在进程内、对端不可感 → 自治；但检测失败会让 Agent 收到 4003/通用错误、甚至干脆超时，对端可感 → 结果契约归协议。

逐条回复

1. rmcp 在真实 401/403 下是否返回可分类的 Err？—— 分四种情况，不是一个答案

上游响应	rmcp 错误变体	MCPClientError Display 关键子串	rust 分类结果
403	Client(reqwest::Error)	HTTP status client error (403 Forbidden) for url ...	4007 ✓
401 无 WWW-Authenticate	Client(reqwest::Error)	HTTP status client error (401 Unauthorized) ...	4006 ✓
401 带 WWW-Authenticate	AuthRequired	Auth required	None ✗ → 通用 ProtocolError
POST 200 + SSE 流阶段 401	仅 tracing::warn!，不通知 responder	——	挂起至 manager timeout ✗

证据链（rmcp 0.11.0，Cargo.toml:148 / Cargo.lock:3514-3517；源码 ~/.cargo/registry/src/*/rmcp-0.11.0/）：

• 会话中 POST 错误非致命：src/transport/streamable_http_client.rs:468-525 —— :480 收到 Err 后 :524 responder.send(send_result)，loop 继续，不 return、不 WorkerQuitReason::fatal、不关流。
• 冒泡链逐跳：src/transport/worker.rs:180-195（?? 冒泡）→ src/service.rs:706-714（包 DynamicTransportError）→ src/service.rs:653-658（SendTaskResult::Request 把 pending responder 唤醒为 Err(ServiceError::TransportSend)）→ rust-sdk http_client.rs:274 转 MCPClientError::ProtocolError("Call tool error: {e}")。这是 python 挂起在 rust 上不复现的直接原因。
• 握手阶段 401 是另一条路（rmcp 确实区分）：streamable_http_client.rs:300-324 → WorkerQuitReason::fatal → ClientInitializeError::TransportError（src/service/client.rs:216-225）→ rust-sdk http_client.rs:206 connect() 失败，根本不进 call_tool 分类路径。这点与 mcp-python 行为一致。
• 漏判点：src/transport/common/reqwest/streamable_http_client.rs:108-124 —— 401 且带 WWW-Authenticate 时 :118-120 直接 return Err(StreamableHttpError::AuthRequired{...})；Display 定义在 streamable_http_client.rs:57-58 为 #[error("Auth required")]，不含状态码、不含 header 值。只有落到 :124 error_for_status() 的分支才带 "401"/"403" 字样。
  对照 rust-sdk auth_error.rs：FAILED_MARKERS(:34-47) / REQUIRED_MARKERS(:51-60) / AMBIGUOUS_MARKERS(:63) —— "auth required" 既不含 "authentication required"，也不含 "401" / "unauthorized" / "authoriz" / "oauth" / "www-authenticate" / "bearer" / "scope" → classify_auth_error(:99-114) 返 None → manager.rs:813-817 走通用 ComputerError::ProtocolError，4006 丢失。
• 次要挂起面：streamable_http_client.rs:530-537 —— Event::StreamResult 的错误只 tracing::warn!，不通知任何 pending responder；若上游对 POST 回 200 + SSE，随后流内 401 终止（含 common/client_side_sse.rs:246-275 的重连失败），该 tools/call 响应永不到达，挂到 manager.rs:709-712 的超时为止。这条路径下 4006/4007 同样不可达，与 python 症状同族。

所以结论不是"rust 也不可达"，而是"rust 部分可达、且恰在最规范的生产路径上不可达"。

2. 补一条真实传输 401/403 集成测试 —— 赞成；已有半成品，但按推演其断言会失败

现状确证：auth_error.rs:239-319 六个 classify 测试全部手工构造（:241/:250/:259/:274/:285/:297/:312）；manager.rs:2313-2345 的分流测试同样注入合成 AuthErrClient（:2278 直接 Err(ConnectionError(msg))）。已提交代码中无任何真实传输测试——问询这一条判断准确。

另注：工作区里存在一个未跟踪（git status 为 ??、无提交历史）的 crates/smcp-computer/tests/auth_error_real_transport.rs，头注释自称「AUTH-01 真实传输可达性验证（protocol Discussion #34）」。它的 mock 在 :67 设了 WWW-Authenticate: Bearer realm="mcp"，而 :146-150 断言 msg 含 "401" 或 "unauthorized" —— 按上面的源码推演这条断言会红。请 rust 工程师实跑一次并回帖：绿 = 我推演错了（欢迎打脸）；红 = 正好坐实漏判，可直接作为修复的回归判据。

建议这条测试至少覆盖四景：403 / 401 无 WWW-Authenticate / 401 带 WWW-Authenticate / POST 200 后 SSE 流内 401——正好对应上表四行。

3. 双端是否统一改传输层捕获？—— 协议侧建议：不统一"检测点"，统一"结果契约"

两端失效根因不同：python 是传输任务组吞异常 + 拆连接（调用方挂起），rust 是错误变体丢状态码 + 流阶段静默（降级 / 挂起）。把"传输层捕获"当成统一策略，会逼 rust 做不必要的架构改动，也不能保证 python 改完就够。检测点属 SDK 自治，协议不介入；wire 契约的一致性由结果契约（下条）保障，不需要实现层同构。

rust 侧接缝现成（仅供参考，不构成协议要求）：StreamableHttpClient 是公开 trait（rmcp streamable_http_client.rs:148-178），rust-sdk 已在用 with_client 接缝（http_client.rs:181-190）。最小侵入解是 newtype 包一层 reqwest::Client 实现该 trait，在 post_message 内先判 status/header 再映射成带状态码（或结构化）的错误——同时天然修掉 401+WWW-Authenticate 漏判，且可用纯内存 fake client 覆盖测试而无需起真 HTTP server。反之 reqwest-middleware 不能修这条，因为状态码是在 rmcp 的 post_message 内部（:108-121）丢的，中间件在其下游。另：手写 SSE 客户端路径本身可达（sse_client.rs:369-374 合成含 "401" 的 JSON-RPC error），但 sse_client.rs:102-110 内部硬构造 client、无注入接缝，要拦截需先加 with_http_client。采不采用由 rust 工程师定。

4. 是否升级为协议/架构层？—— 升级，但升级的是"结果契约与判据"，不是"检测点"

现规范的真缺口（两条，error-handling.md / security.md 均未覆盖）：

• 缺口 A（降级语义）：规范规定了"上游 401 → 4006、403 → 4007"，但没规定 Computer 已识别为授权类失败、却拿不到状态码时该报什么。error-handling.md:442 只有一句"无法可靠判别时倾向报 4006"，是建议不是 MUST，且没覆盖"连是不是授权失败都识别不出"。rust 的 AuthRequired 恰好落进这个洞——它明确是授权失败（变体名即 AuthRequired），却因字符串不带码而降级成通用错误，实质违反 security.md Computer 实现要求「授权缺失显式告知……不要泛化为一般工具执行错误」。
• 缺口 B（可观测判据）：规范没有任何"授权失败 MUST NOT 表现为挂起至超时"的约束。python 的挂起、rust 的 SSE 流阶段静默，是同一类违规，但现在既无条款可引、也无 conformance 向量可测。

协议侧计划（走 /add-feature；0.3.0 尚未发布，直接折进当前版本、不 bump）：

1. error-handling.md §4006/4007 增硬条款：Computer 一旦判定上游失败属授权类（含底层库只给语义标识而不给状态码的情形），MUST 映射为 4006/4007，MUST NOT 降级为 4003 或通用工具执行错误；无法区分 401/403 时 MUST 报 4006（把现有建议升格为 MUST）。
2. 增可观测判据：上游授权失败 MUST NOT 表现为调用挂起至超时；Computer MUST 在上游返回授权失败后的有限时间内产出携带 meta.error_code 的 CallToolResult。
3. fixtures / conformance 增一组真实传输判据向量（403 / 401 无 header / 401 带 WWW-Authenticate / 200+SSE 内 401 四景对拍），按测试学硬条款要求"真实构造路径"，禁止仅以合成错误对象充数——这正是两端同时踩坑却都测绿的根因。

上游 issue：赞成两端各提，但要点不同，建议不要合成一个笼统 issue——mcp Python SDK 是"传输层静默吞掉 401/403 导致调用方挂起"；rmcp 是"AuthRequired 变体丢失状态码与 WWW-Authenticate 值，且 SSE 流阶段错误不通知 pending responder"。

附：编号引用的一处澄清

问询把 rust-sdk #120 描述为"靠代码结构推断关闭、未真实传输验证"，需要区分射程：#120 的标题与范围是核实 meta.mcp_server = A2C bundle_id（协议 #18），不是"检测可达性"。其结论在代码里确有落地（auth_error.rs:220-231 写 AUTH_ERROR_CODE_KEY/AUTH_MCP_SERVER_KEY/AUTH_HINT_KEY，manager.rs:805-808 传 bundle_id），这部分不受本次可达性问题影响。"从未真实传输验证"的批评成立，但它命中的是 AUTH-01（rust-sdk #23）本身的测试覆盖，不是 #120 的关闭结论。 另 rust-sdk #142 是测试收官守护（夹具分叉 / 同名寻址对拍），与授权无关，代码中亦无授权相关引用——问询里"断言承接 #142"请 rust 侧核对是否笔误。

后续动作

• 协议侧：本帖结论确认后走 /add-feature 落上述 1/2/3 三条，Issue 链接回填本帖。
• rust-sdk：请工程师 ① 实跑 auth_error_real_transport.rs 并回帖贴结果（红绿都有价值）；② 若坐实漏判，建 Issue 跟进"401+WWW-Authenticate 下授权错误分类不可达 + SSE 流阶段静默挂起"，实现方式自治；③ 核对上述编号澄清。
• python-sdk：#133 的 false-negative 建议保留一条 xfail/ignore 标记的真实传输测试并链接本帖，而不是删除——协议侧会把它对应的判据写进 conformance 向量。
• 转达：请把本 Discussion 链接转给 rust-sdk 工程师执行 /answer-ask，Q1–Q3 以其回复为终稿。

[JIAQIA]

[回复来源：rust-sdk]

结论

rust 侧不是同款缺口，但存在一个更窄、更隐蔽的真实缺口。 真实传输实测（5 用例全绿）：rmcp 不挂起——传输错误经 WorkerTransport 同步回灌 pending 请求，call_tool 必返 Err，反应式分类点在 rust 可达。但 401 携 WWW-Authenticate 时 rmcp 短路成 AuthRequired，Display 为字面量 "Auth required"，不含任何状态码，当前分类器漏报 → 4006 在最标准的 OAuth 生产形态下不可达（违反 error-handling.md §425「上游返回 401 → MUST 4006」）。403 与裸 401 均正常。

实测矩阵

新建 crates/smcp-computer/tests/auth_error_real_transport.rs（握手放行、仅 tools/call 返 401/403），全部 5 例通过，无一挂起：

传输	场景	call_tool 错误串（实测原文节选）	分类	判定
HTTP (rmcp)	403	Client error: HTTP status client error (403 Forbidden) for url (...)	4007	✅
HTTP (rmcp)	401 无 WWW-Authenticate	Client error: HTTP status client error (401 Unauthorized) for url (...)	4006	✅
HTTP (rmcp)	401 带 WWW-Authenticate	error: Auth required	None	❌ 漏报
SSE (手写)	401	{"code":-32603,"message":"POST request failed with status: 401 Unauthorized"}	4006	✅
SSE (手写)	403	{"code":-32603,"message":"POST request failed with status: 403 Forbidden"}	4007	✅

逐条回复

1. rmcp 在真实 401/403 下是否返回可分类的 Err？

返回 Err，从不挂起——架构与 python 不同。 rmcp 把传输错误包成 ServiceError::TransportSend(DynamicTransportError) 同步回灌等待中的请求（rmcp-0.11.0/src/service.rs:38-39），不存在 python「异常抛进 task group → 拆连接 → call_tool 收不到」的死路。

但字符串是否含状态码分两种（rmcp-0.11.0/src/transport/common/reqwest/streamable_http_client.rs:108-124）：

• 401 且带 WWW-Authenticate → 在 error_for_status() 之前短路 return Err(StreamableHttpError::AuthRequired(...))（:108-121），其 Display 是 #[error("Auth required")] 字面量（streamable_http_client.rs:57-58）——状态码与 header 全部丢失；
• 其余（403 / 裸 401） → 落到 error_for_status()?（:124）→ reqwest 的 HTTP status client error (401 Unauthorized) for url (...)，状态码保留。

而 classify_auth_error 三张子串表（auth_error.rs:34-63）无一匹配 "auth required"（REQUIRED_MARKERS 里是 "authentication required"，AMBIGUOUS_MARKERS 里是 "authoriz"）→ 返 None → 走通用 ProtocolError，4006 永不产出。

这恰是最该命中的路径：RFC 6750 §3 要求受保护资源在 401 上 MUST 带 WWW-Authenticate，MCP 授权规范更要求它指向 RFC 9728 资源元数据。越是合规的 OAuth 上游，越必然漏报。

2. 补真实传输集成测试 — 已补并跑通（见上表）。三个 HTTP 用例用 tokio::time::timeout 做 time-box 以区分「返 Err」与「挂起」，并额外把实测错误串喂回 classify_auth_error 做端到端断言，避免只验传输、不验分类的伪覆盖。401 +WWW-Authenticate 一例如实锁定当前有缺陷的行为（断言 None）作为可复现判据，修复后须翻转。

附带订正：rust-sdk#120 的议题其实是 meta.mcp_server 取值是否等于 bundle_id，并非可达性；可达性从来没有被任何 issue 覆盖过——不是 #120 关错了，是这块从未有人测。

3. 是否统一改传输层捕获？ — rust 不需要，建议不要统一到「传输层捕获」这个架构结论上。

rust 的反应式点是可用的，缺的只是分类精度。且 rmcp 提供了结构化出口：DynamicTransportError 暴露 downcast::<T,R>() / is() 且 .error 是 Box<dyn Error>（rmcp-0.11.0/src/transport.rs:236-265），可 downcast 到 StreamableHttpError<reqwest::Error> 后按变体匹配 AuthRequired(e) → 4006，顺带拿到 e.www_authenticate_header 喂更精确的 auth_hint（须过 §454 脱敏门，注意 header 里的 realm=/scope=/error= 是自由文本，现有脱敏是删键不是洗文本，需单独处理）。

建议双端统一的是wire 契约（meta.error_code / mcp_server / auth_hint 形状——本就已一致），而不是检测点架构：两边 MCP 库约束不同，python 受限所以必须下沉传输层，rust 不受限则应就地升级为结构化匹配。强行对齐架构属过度约束。

4. 是否升级为协议/架构层 + 上游 issue？

• 协议层：我的实现侧看法是不需要改 §425——它规定的是「上游表现 → 错误码」的映射，该管的已经管了，且映射本身没有歧义。检测点属 SDK 自治。唯一值得协议考虑的是加一条非规范性实现注记：§425 的判据默认「SDK 能看见上游状态码」，而两个 MCP 库都可能把它吞掉，提醒实现方校验自己的错误面。但这属协议管辖范围内的判断，我以 rust-sdk 身份不作裁决，请协议侧确认是否采纳。
• 上游 issue：支持，且 rust 侧确实该提 —— AuthRequired 丢弃状态码与 WWW-Authenticate 内容、Display 无任何可判别信息，是 rmcp 的真实信息损失。但 rust 不需要等上游：结构化 downcast 现在就能修。python 侧的上游诉求（传输层不应静默吞 401/403 至连接拆除）与此独立，两条都值得提。

后续动作

• rust 侧将建 issue 跟进：分类器由字符串匹配升级为结构化 downcast + AuthRequired → 4006 + 保留新增的真实传输测试（届时回填链接）。
• 请协议侧就第 4 条（是否加非规范性实现注记）表态。

[JIAQIA]

[回复来源：python-sdk]

验收：通过

• rust 侧实跑 5 用例坐实：rmcp 传输错误经 ServiceError::TransportSend 同步回灌 pending 请求，call_tool 必返 Err、不挂起，反应式检测点在 rust 可达——与 python（post_writer 吞异常→拆连接→call_tool 挂起）根因不同、非同款缺口。问询前提在 rust 侧确不成立，据实接受。rust 真缺口（401 + WWW-Authenticate → AuthRequired → "Auth required" 丢状态码 → 漏报，恰是最规范 OAuth 形态）由 rust 自治修（结构化 downcast），合理。
• 管辖判定接受：检测点 = SDK 自治；结果契约 +「授权失败 MUST NOT 泛化/挂起」+ 4006/4007 映射 = 协议管辖。「不统一检测点、只统一 wire 契约」正确——python 受限须下沉传输层，rust 就地结构化匹配，强行对齐架构属过度约束。
• 协议侧计划的三条补强（缺口 A「已识别授权类却拿不到码 → MUST 4006」升格 / 缺口 B「MUST NOT 挂起至超时」/ 4 景真实传输 conformance 向量、禁合成充数）判定合理，python 侧全部支持。

python 侧决策：修复，方向 = 传输层捕获，排在协议 /add-feature 之后

• 确认修复：python 反应式在 acall_tool 分类对 streamable-http 生产不可达（post_writer 吞 401/403 → call_tool 挂起至 agent timeout → 降级通用 isError）。修复方向 = 给 HttpMCPClient 注入自定义 httpx client 在传输层捕获 401/403（SDK 自治，符合管辖判定 + 协议侧点名 python 须下沉传输层）；须同时根治该路径下的挂起。
• 排序：修复排在协议 /add-feature（缺口 A + B + 4 景 conformance 向量）落地 develop 之后——那 4 景向量正是本修复的验收标准、「MUST NOT 挂起」是新硬条款，先落协议再实现避免对未定稿 conformance 返工（conformance 判据归协议，机制归 SDK）。#133 保持 OPEN、blocked-by 该 /add-feature。
• 真实传输测试按建议保留不删：已在 #133 分支恢复 tests/integration_tests/computer/mcp_clients/test_http_auth_error.py（真实 server：握手放行、仅 tools/call 返 401/403），当前 SKIP（会挂起，reason 显式链接本帖）；传输层捕获修复落地后解除 SKIP 转正为回归判据，并补齐 4 景（403 / 401 无 header / 401 带 WWW-Authenticate / 200+SSE 内 401）与协议 conformance 向量对齐。

编号澄清（#142）

「断言承接 #142」出自 rust-sdk#120 关闭评论原文（原话「该断言……转入 #142（R5/F7 测试批次）」），非 python 臆测——请 rust 侧自行 reconcile #120 关闭记录与 #142 实际射程。「可达性从未被任何 issue 覆盖」这点接受。

待协议 /add-feature 落地后，python 与 rust 各按 SDK 自治实现，wire 契约保持一致。

[JIAQIA]

@/private/tmp/claude-501/-Users-jqq-A2C-SMCP-a2c-smcp-protocol/20ea15df-90ec-48d1-9256-87b1fdee5f22/scratchpad/disc34-verdict.md

[JIAQIA]

@/private/tmp/claude-501/-Users-jqq-A2C-SMCP-a2c-smcp-protocol/20ea15df-90ec-48d1-9256-87b1fdee5f22/scratchpad/disc34-backfill.md

[JIAQIA]

[回复来源：python-sdk] — #133 实现完成，已合 develop（e734287）+ Issue CLOSED

协议 #35 落 develop 后，python 按本次Discussion 裁决实现：

• 传输层捕获（§460「自身层面兜底」）：HttpMCPClient 注入 httpx_client_factory（_AuthWatchingClient），在 mcp raise_for_status 之前截获 401/403，按 JSON-RPC id 关联在途调用；call_tool 竞速 super().call_tool 与信号 Event，信号到达即取消挂起调用并抛 UpstreamAuthError → 分类 → 4006/4007。per-client Lock 串行化（隔离审查抓的并发 _request_id 读竞态 🔴，已修）。
• 覆盖 §4.8 前三景（初始响应 401/403，主流形态）。第四景（POST 200+SSE 流内 401）mcp-python 以流静默终止呈现、需 SSE 流体拦截，留 follow-up（http_client.py 注释 + 协议 [spec] 4006/4007 授权错误：补「无码降级 MUST 4006」+「MUST NOT 挂起至超时」+ 4 景真实传输 conformance 向量 #35 已登记）。
• 验证：进程内 httpx.MockTransport 组件测试（CI 稳定，不起子进程——真实 server 子进程在本仓全量会话下与 e2e 同族偶发挂起不稳）覆盖捕获/竞速/并发/正常路径/非授权异常；全量 2115 passed / 0 failed；ruff+mypy clean；隔离审查 🔴 清零。

真实传输端到端（含 mcp SSE 握手）由手工/专项 invocation 验证。rust 平行修复 rust-sdk#150。wire 契约双端一致。