Skip to content

fix(pi): stop rewriting request payloads and widen malformed-body retry - #100

Open
CtriXin wants to merge 1 commit into
devfrom
issue-99-pi-retry-scope
Open

fix(pi): stop rewriting request payloads and widen malformed-body retry#100
CtriXin wants to merge 1 commit into
devfrom
issue-99-pi-retry-scope

Conversation

@CtriXin

@CtriXin CtriXin commented Jul 31, 2026

Copy link
Copy Markdown
Owner

Closes #99

跟进 #97 / #98 的诊断结论。这个 PR 只动 scripts/pi-retry-extension.mjs 和它的测试。

1. 移除 before_provider_request 归一化

它对报错零作用JSON.stringify 本来就转义整个 C0 区间,抓包实测确认 pi 发出的字节里没有任何原始控制字节。

它的副作用是真的

.replace(/\\x([0-9a-f]{2})/gi, ...)
.replace(/\\([aev])/gi, ...)
.replace(/\\0(?![0-9])/g, "\\u0000")

这几条作用在每个字符串上,会把源码里字面的 \x41 / \a / \e / \v / \0 静默改写成 \u00XX。编辑含这些文本的文件时内容会被破坏。

2. 扩大 malformed-body retry 的范围

原来锁死在 mms-newapi-personal-tokyo 前缀,所以 mms-uscrsopenai 报的 400 "Invalid JSON" 不进 retry,直接硬失败。

改为:MMS 托管的 provider(mms- 前缀)+ 窄 signature。

这里比 issue 里写的范围更宽,需要 reviewer 确认:没有只加 mms-uscrsopenai,而是覆盖所有 mms- provider。理由是这个损坏在两个不同 relay 上都出现过,本来就不是 provider-specific 的;只加一个 relay 等于等着下一个 relay 再踩一次。如果希望收窄成显式白名单,我改。

signature 保持窄,只匹配"请求体没解析成功":

/invalid character .* in string (literal|escape code)|invalid json/i

真实的校验失败(invalid request bodymodel_not_found)仍然照常抛出来,测试里有覆盖。

边界

  • 未动 provider / model 路由
  • 未动其它两个 message_end 分支(codex token 失效、antigravity capacity)
  • 未动任何 Python 侧启动链路

验证

  • node --check 通过
  • tests/test_pi_retry_extension.py 3 passed,重写为覆盖:没有注册任何请求钩子、两个 relay 的两种 signature 都 retry、既有 auth 分支不变、真实校验错误不被 retry 吞掉、非 MMS provider 不参与
  • tests/test_pi_launcher.py 39 passed
  • live smoke:把改后的 extension 用 -e 显式加载进真实 pi 0.83.0,对 Tokyo relay 跑通,返回 OK
  • 完整 fresh-user gate:390 passed / 1 failed。那个 failed 是 test_overlay_web_access_session_entries_merges_session_and_web_access_skill,在干净 dev 上同样失败,既有红灯,与本改动无关

残余风险

retry 会把"请求体畸形"这类 400 变成重试。如果将来出现一个真的由 pi 构造错误请求导致的稳定 400,会被重试 8 次才暴露出来,症状是变慢而不是立刻报错。#98 的抓包开关就是用来区分这两种情况的。

https://claude.ai/code/session_01VA2vRxuCpZsLmXR8sLeUgG

The before_provider_request normalization could not affect the reported relay
400: JSON.stringify already escapes the whole C0 range, and captured traffic
confirms Pi puts no raw control bytes on the wire. What it did do was rewrite
literal escape text, so editing a file containing \x41, \a, \e, \v or \0 as
plain text silently corrupted the content. Remove the hook entirely.

The retry that does help was gated on the Tokyo provider prefix, so the same
corruption arriving from mms-uscrsopenai as 400 "Invalid JSON" hard-failed
instead. The failures were observed on two different relays with the offending
byte spread across the whole byte space, so scope the retry to MMS-managed
providers and add the Invalid JSON signature. The signatures stay narrow enough
that genuine rejections such as invalid request body and model_not_found still
surface.

Refs #99

Agent-Model: claude-fable-5
Agent-Family: anthropic
Agent-Session: 2d6d2047-8869-4b65-9345-349181832167
Agent-Step: 0.0.2

Claude-Session: https://claude.ai/code/session_01VA2vRxuCpZsLmXR8sLeUgG
@github-actions

Copy link
Copy Markdown

Digger: no new failures

  • Diff: 2 files, +80/-93.
  • Validation: no new failures; existing baseline: python3 -m pytest -q.
  • Findings: [P2] Existing baseline validation failures remain. No new head failure was introduced, but the base still has failing validation.
  • MMS semantic review: skipped.
  • Details: see Actions artifact digger.

Digger automatic review. Full packet: Actions artifact digger.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant