fix(release): raise prepared package size budget to 112 MiB (#10775) - #10788
qwen-code-dev-bot wants to merge 1 commit into
Conversation
The prepared package now measures 101,897,981 bytes (97.18 MiB), 1.18 MiB over the 96 MiB budget, so `npm run prepare:package` throws — and because the Docker sandbox image's builder stage ends with that command, every docker build failed with it: the release integration_docker job and all three e2e sandbox:docker shards, on three different pool hosts, the e2e build retry included. No host-side lane runs prepare:package, so quality, workspace tests and integration_none stayed green and the breach only surfaced inside `docker build`; the publish job would have hit the same gate on the same run. The growth is the OpenTUI renderer chunk (2,002,450 bytes) that shipped with the QWEN_TUI_RENDERER activation — without it the package measures 95.27 MiB, under the old budget. Raise the budget to 112 MiB, about 15% headroom over the measured size (the packed tarball is 27.0 MB), and move the pinning test with it: the same remediation as #6688 (80 -> 85 MiB) and #6691 (85 -> 96 MiB), the latter unblocking the identical v0.19.9 docker sandbox build failure.
Autofix E2E report — issue #10775 (Release Failed for v0.22.3-nightly.20260902.7df5ac6898)What failedRelease run 33594509319 (tag The job carries a single generic annotation, Root cause (reproduced locally)The Dockerfile's builder stage ends with: RUN QWEN_SKIP_PREPARE=1 npm ci \
&& npm run build \
&& npm run bundle \
&& npm run prepare:package \
&& cd dist && npm pack
Why nothing else caught it: no host-side lane runs What pushed it over: The CI timeline matches the attribution:
Every failing docker leg in Precedent: this exact failure mode has been remediated twice before by raising the budget — The fixRaise VerificationDocker itself is unavailable in this sandbox, so the container-only tail of the Dockerfile builder stage (
Not validated / notes for maintainers
中文说明Autofix E2E 报告 —— issue #10775（v0.22.3-nightly.20260902.7df5ac6898 发布失败）失败的内容发布运行 33594509319（标签 该 job 只有一条通用批注 根因（已在本地复现）Dockerfile 的 builder 阶段最后执行： RUN QWEN_SKIP_PREPARE=1 npm ci \
&& npm run build \
&& npm run bundle \
&& npm run prepare:package \
&& cd dist && npm pack
为什么其他环节没有发现： 宿主机侧没有任何通道会运行 是什么把体积推过上限： CI 时间线与该归因一致：
先例： 完全相同的失败模式此前已经通过提高预算处理过两次 —— 修复将 验证本环境无法使用 docker，因此以真实产物直接运行 Dockerfile builder 阶段中"仅容器内执行"的尾部命令（
未验证 / 给维护者的说明
🧠 Handled by Qwen Code · model/模型 |
|
The failure this PR targets was already fixed on Everything in this diff is already on the default branch: the test change is byte-for-byte identical to what #10781 landed, and the constant change is there too — which is why this PR now shows as conflicting. Applying it to One loose end for a maintainer: this PR's linked issue #10775 is still open even though its root cause was resolved by that same commit — #10774 and #10775 are two issues for the one failure, so #10775 likely deserves the same treatment. 中文说明这个 PR 针对的失败已经在 这份 diff 的所有内容都已在默认分支上：测试改动与 #10781 合入的内容逐字节相同， 给维护者的一个遗留事项：本 PR 关联的 issue #10775 仍然处于打开状态，但其根因 — Qwen Code · qwen3.8-max |
2 participants
What this PR does
Raises the budget that the packaging step enforces on the prepared npm package from 96 MiB to 112 MiB, and moves the test that pins that default along with it. Nothing else changes: no packaging logic, no bundle content, and no workflow is touched.
Why it's needed
The nightly release
v0.22.3-nightly.20260902.7df5ac6898failed with only one red job, the docker integration lane, and the failure was not in any test. The Docker sandbox image's builder stage ends by preparing and packing the distributable package, and that preparation refuses to run once the package exceeds its size budget. The package had grown to 101,897,981 bytes (97.18 MiB) against a 100,663,296-byte (96 MiB) budget, so the image build threw and every docker-sandbox leg on the runner pool failed with it — the release's docker integration job plus all three E2E docker shards, across ten distinct hosts in all three host groups, over five runs and three commits, with the E2E leg's one build retry failing identically.The growth is legitimate: a single new 1.91 MiB renderer chunk that shipped when the OpenTUI backend was activated behind
QWEN_TUI_RENDERER. Without that chunk the package measures 95.27 MiB, under the old budget. No source maps, test files, or dependency trees are in the measured set. Because no host-side lane prepares the package, the breach is invisible until a docker build runs, which is why the same commit had green quality, workspace, and no-sandbox integration lanes. The release's publish step prepares the package too, so that nightly could not have published even if the docker lane had passed.Raising the budget is the remediation this repository has already used twice for this exact failure, including once with the same symptom during the v0.19.9 release. 112 MiB leaves about 15% headroom over the measured size — comparable to the headroom the previous bump left — while the packed tarball is only 27.0 MB, so no registry limit is near. The guard still trips on an accidental large inclusion, and the separate scan that keeps the removed browser-automation dependencies out of the package is untouched.
Reviewer Test Plan
How to verify
mainbefore this change, build the bundle (npm run build && npm run bundle) and runnode scripts/prepare-package.js. It exits 1 withError: Prepared package unpacked size 101897981 bytes exceeds 100663296 bytes. This is the exact command the Docker builder stage runs, so it reproduces the release failure without needing a docker daemon.npm packinsidedist/then succeeds, reportingpackage size: 27.0 MB,unpacked size: 101.9 MB,total files: 1023.npx vitest run --config ./scripts/tests/vitest.config.ts scripts/tests/package-assets.test.js— 34 passed. The budget test now proves both sides of the new default: 111 MiB of content prepares cleanly and 112 MiB is rejected withexceeds 117440512 bytes.expected [Function] to not throw an error. Restore 112 MiB and both go green.Evidence (Before & After)
N/A — no user-visible or TUI surface. The observable change is CI: before,
Run Docker Integration Testsfailed in 9m13s having never reached a test, and each E2E docker shard loggedsandbox image build failed; retrying oncebefore exiting 1; after, the packaging step that the image build ends with completes.Tested on
Environment (optional)
Linux self-hosted runner checkout of
main@7df5ac6898with the repository's ownnpm ciinstall; bundle produced bynpm run build && npm run bundle. No docker daemon is available in that environment, so the container-only tail of the Dockerfile builder stage was executed directly on the host as the surrogate.npm packneeded a scratch cache directory because the runner's~/.npmholds root-owned files.Risk & Scope
docker builditself was not run (no daemon available); the surrogate covers the command that threw plus thenpm packthat follows it. Also left alone: the budget is enforced only inside the docker build and the publish job, so a future breach will again surface as a pool-wide docker outage rather than a readable host-side failure — running the packaging step in a host-side lane would fix that, and it belongs in a workflow change of its own.Linked Issues
Fixes #10775
中文说明
这个 PR 做了什么
将打包步骤对"准备好的 npm 包体"所强制执行的体积预算从 96 MiB 提高到 112 MiB，并同步移动固定该默认值的测试。其他内容一律未动：没有改打包逻辑、没有改 bundle 内容、也没有改任何工作流。
为什么需要
nightly 发布
v0.22.3-nightly.20260902.7df5ac6898失败时只有一个红 job —— docker 集成通道 —— 而且失败点不在任何测试里。Docker 沙箱镜像的 builder 阶段最后会准备并打包可发布的包体，而一旦包体超过体积预算，这个准备步骤就会拒绝执行。当时包体已增长到 101,897,981 字节（97.18 MiB），而预算是 100,663,296 字节（96 MiB），于是镜像构建抛错，池上所有 docker 沙箱环节随之失败 —— 发布的 docker 集成 job 加上三个 E2E docker 分片，在三个主机组的十台不同主机上、五次运行、三个提交之间反复出现，E2E 环节那一次构建重试也以完全相同的方式失败。这次增长是合理的：只有一个 1.91 MiB 的渲染器 chunk，是在 OpenTUI 后端通过
QWEN_TUI_RENDERER开关启用时引入的。去掉这个 chunk，包体为 95.27 MiB，低于旧预算。统计范围内没有 source map、没有测试文件、也没有依赖目录。由于宿主机侧没有任何通道会准备包体，这个越界在 docker 构建运行之前是不可见的 —— 这也是为什么同一个提交的质量检查、workspace 测试和无沙箱集成通道全是绿的。发布的 publish 步骤同样会准备包体，所以即使 docker 通道通过，那次 nightly 也无法发布。提高预算是本仓库针对这一完全相同故障已经采用过两次的处理方式，其中一次正是在 v0.19.9 发布期间出现相同症状时。112 MiB 相对实测体积留出约 15% 余量 —— 与上一次提高预算留出的余量相当 —— 而打包后的 tarball 只有 27.0 MB，距离任何 registry 限制都很远。该保护在意外混入大体积内容时仍会触发，而用于阻止已移除的浏览器自动化依赖回流的敏感字符串扫描也未被触碰。
审阅者测试计划
如何验证
main上，构建 bundle（npm run build && npm run bundle）并运行node scripts/prepare-package.js。它会以退出码 1 结束，并报Error: Prepared package unpacked size 101897981 bytes exceeds 100663296 bytes。这正是 Docker builder 阶段执行的命令，因此无需 docker 守护进程即可复现发布失败。dist/中执行npm pack会成功，输出package size: 27.0 MB、unpacked size: 101.9 MB、total files: 1023。npx vitest run --config ./scripts/tests/vitest.config.ts scripts/tests/package-assets.test.js—— 34 个测试通过。预算测试现在同时验证新默认值的两侧：111 MiB 内容可以正常打包，112 MiB 会被拒绝并报exceeds 117440512 bytes。expected [Function] to not throw an error失败。改回 112 MiB 后两者重新变绿。前后对比证据
N/A —— 没有用户可见或 TUI 层面的变化。可观察到的变化在 CI：改动前，
Run Docker Integration Tests在 9 分 13 秒后失败且从未跑到任何测试，每个 E2E docker 分片都会先打印sandbox image build failed; retrying once再以退出码 1 结束；改动后，镜像构建所依赖的最后一个打包步骤可以正常完成。测试环境
环境（可选）
Linux 自托管 runner 上
main@7df5ac6898的检出，使用仓库自身的npm ci安装；bundle 由npm run build && npm run bundle生成。该环境没有可用的 docker 守护进程，因此把 Dockerfile builder 阶段中"仅容器内执行"的尾部命令直接在宿主机上运行作为替代验证。npm pack需要一个临时缓存目录，因为该 runner 的~/.npm中存在 root 所有的文件。风险与范围
docker build（环境无守护进程）；替代验证覆盖了抛错的那条命令及其后的npm pack。同样未处理的是：该预算只在 docker 构建和 publish job 内强制执行，所以将来的越界仍会表现为全池 docker 中断，而不是宿主机侧可读的失败 —— 在宿主机侧通道运行打包步骤可以解决这点，那属于一次独立的工作流改动。关联 Issue
Fixes #10775