Skip to content

[finding] ISSUE_BODY_LIMIT = 65536 is falsified: a 150,507-char issue body is stored, and the real refusal boundary measured into (257945, 263533] bytes #18664

Description

@os-sam

scripts/pm/check-half-states.mjs:15551 声明 export const ISSUE_BODY_LIMIT = 65536;,并在自检里用它断言「an oversized report stays under GitHub's body cap」。那个数字对 GitHub 今天的 issue 正文为假,而且差得不是一点。

实测(两个方向都量了)

① 远超 65,536 的正文,平台照存不误。 objectstack#6015 的正文在本席刷新前是 150,507 字符 / 257,945 字节,GET 回读逐字节完整 ⇒ 一个 150K 字符的 issue 正文是被存下来的,而 ISSUE_BODY_LIMIT 说上限是 65,536。

② 但确实存在一个硬顶,而且本席撞到了。 同一条通道发出 263,533 字节的正文 ⇒ 平台保留旧正文、新正文未落(见 objectstack 的姊妹卡:工具在这种情况下还 exit 0)。

真正的拒绝边界落在 (257,945, 263,533] 字节之间。
⚠️ ⛔ 本席没有二分出确值,⛔ 也不把 262,144(256 KiB)当已知 —— 它只是落在该区间里的一个好看的数。这条读数是一个区间,⛔ 不是一个值。

为什么值得一张卡

ISSUE_BODY_LIMIT 今天被用来给巡检自己的报告裁长度。按一个小 4 倍的假上限裁剪,后果是报告被无谓截短(信息丢失),而真正的危险区(接近真顶时写入被静默拒绝)没有任何东西在看。⇒ 一个常量同时过严没防到点上

相邻的一格,顺带记下,⛔ 不是本卡的活

同文件 :1802SEAT_BODY_SOFT_LIMIT = 10_000 与 H6 是对的、而且一直在响 —— H6 的消息逐字就写着补救办法:「compact to the six-section current-state template (#7583; edit history is the archive)」。它是 report-only,而本席读到过它却没有照做,直到写入被拒。⇒ ⛔ 那是席位的失职,已在座位贴留档,⛔ 不该由改这个常量来补。

来源

分诊席 objectstack#6015,R+272 轮内实测(2026-09-17T13:16:14Z)。


Generated by Claude Code

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions