fix(release): raise prepared package size limit to 96 MB (#6687) - #6691
Merged
Conversation
The assertPreparedPackageSize check introduced after v0.19.8 set an 80 MB ceiling, but the current package is 80.58 MB — 597 KB over — causing the Docker sandbox build to fail during the v0.19.9 release. Bump to 96 MB to accommodate normal growth with ample headroom.
Collaborator
Author
E2E Test ReportSummaryThe v0.19.9 release failed because the Root CauseThe FixIncreased Verification
Package Size Breakdown (current)
|
Collaborator
|
Thanks for the PR! Template looks good ✓ Problem: Observed and real — the Direction: Raising the size ceiling is the right call — it's a safety guardrail, not a performance target. The package has grown naturally through feature additions. However, main has already been updated to 85 MB by PR #6688 ( Merge conflict: This PR is currently CONFLICTING — the value on Size: 1 file, 2 production lines (1 addition + 1 deletion). Not core infrastructure — no gate concerns. Approach: Minimal, single-line change — exactly what's needed. The question now is whether the already-merged 85 MB limit resolves the issue, or if the higher 96 MB target is still needed for future headroom. If 85 MB is enough, this PR can be closed; if not, a rebase with the updated delta would be the right move. Flagging this for discussion before diving deeper — the merge conflict needs resolution first. 中文说明感谢贡献！ 模板完整 ✓ 问题： 已观测到的真实问题 — 方向： 提高大小上限是正确的 — 这是安全护栏，不是性能目标。包大小通过功能添加自然增长。但是 main 已经通过 PR #6688 ( 合并冲突： 此 PR 当前存在 冲突 — 规模： 1 个文件，2 行生产代码（1 增 1 删）。非核心基础设施 — 无门禁问题。 方案： 最小化单行改动 — 正是所需要的。现在的问题是已合并的 85 MB 限制是否解决了问题，还是需要更高的 96 MB 目标来预留未来空间。如果 85 MB 足够，可以关闭此 PR；如果不够，rebase 后更新差值即可。 先提出来讨论，合并冲突需要先解决。 — Qwen Code · qwen3.7-max |
Collaborator
Code ReviewThe single-line change (constant from 80→96) is correct in isolation — no security issues, no logic bugs in the However, two issues found:
No other concerns — the Real-Scenario TestingTests run on current Cannot test the PR's actual 96 MiB change due to merge conflict — the PR branch does not apply cleanly on top of current 中文说明代码审查单行常量改动（80→96）本身正确 — 无安全问题， 但发现两个问题：
其他方面没有问题 — 真实场景测试在当前 由于合并冲突，无法测试 PR 的 96 MiB 实际改动 — PR 分支无法干净地应用到当前 — Qwen Code · qwen3.7-max |
Collaborator
VerdictThe motivation is solid — the v0.19.9 release was blocked by the 80 MB size check, and raising the ceiling is the right fix for a safety guardrail that's not a performance target. The single-line change is exactly as minimal as it should be. But this PR can't merge as-is for two reasons:
Both are straightforward fixes. If the author rebases and updates the test, happy to re-review. 中文说明结论动机合理 — v0.19.9 发布被 80 MB 大小检查阻塞，提高上限对于安全护栏来说是正确的修复。单行改动足够最小化。 但此 PR 目前无法合并，原因有二：
两个问题都可以快速修复。如果作者 rebase 并更新测试，乐意重新审查。 — Qwen Code · qwen3.7-max |
qwen-code-ci-bot
requested changes
Jul 10, 2026
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
Collaborator
There was a problem hiding this comment.
Two blockers: (1) merge conflict — main already has 85 MiB from PR #6688, needs rebase; (2) test at scripts/tests/package-assets.test.js:328 hardcodes the 85 MiB default and would fail with a 96 MiB limit. Both are quick fixes — happy to re-review once resolved.
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
Collaborator
There was a problem hiding this comment.
Reviewed — no blockers. Suggestion-level recommendations are in the Suggestion summary comment below.
Collaborator
Suggestions — commit
|
| File | Issue | Suggested fix |
|---|---|---|
scripts/prepare-package.js:22 |
PR description inaccuracies: The body states the baseline is 80 MB, but origin/main already has 85 MiB (PR #6688). The "~19% headroom" claim is actually ~12.9% from 85 MiB. The "Before" error output (83886080 bytes) shows the 80 MiB limit that no longer exists. After rebase, the effective change is 85→96 MiB. |
Update PR body to say "from 85 MiB to 96 MiB," correct headroom to ~12.9%, and update the "Before" error to reflect the current 85 MiB state. |
| N/A (meta) | CI review's test concern is a false positive: The CHANGES_REQUESTED review by @qwen-code-ci-bot claimed scripts/tests/package-assets.test.js:328 hardcodes the 85 MiB default and would fail with a 96 MiB limit. Verified: the test uses maxPackageUnpackedBytes: 50_000 override and is fully decoupled from the production constant. Only the merge conflict is a real blocker. |
Dismiss the test concern from the existing review. Once rebased onto current main, the PR should be merge-ready. |
— qwen3.7-max via Qwen Code /review
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Collaborator
Author
|
🤖 Addressed the latest review feedback (round 1/5). What changed, and what I pushed back on: Address Review Summary — PR #6691Feedback Triage1. Merge conflict — main has 85 MiB from PR #6688 (Required)Decision: Fixed. Merged 2. Test at scripts/tests/package-assets.test.js:328 hardcodes 85 MiB (Required)Decision: Fixed. Updated the test "enforces a 96 MiB default unpacked size budget":
Conflict NotesMerged Changes Made
Verification Results
Base-conflict check: conflicted with main — resolved in this push. Re-review when you have a moment. After round 5 this bot stops and leaves the PR for a human. |
Contributor
Code Coverage Summary
CLI Package - Full Text ReportCore Package - Full Text ReportFor detailed HTML reports, please see the 'coverage-reports-22.x-ubuntu-latest' artifact from the main CI run. |
qwen-code-ci-bot
approved these changes
Jul 10, 2026
qwen-code-ci-bot
left a comment
qwen-code-ci-bot
left a comment
Collaborator
There was a problem hiding this comment.
No issues found. LGTM! ✅
— qwen3.7-max via Qwen Code /review
wenshao
approved these changes
Jul 10, 2026
pull Bot
pushed a commit
to edisplay/qwen-code
that referenced
this pull request
Sep 2, 2026
…ed package early (QwenLM#10784) * fix(release): raise the package size budget and stop hiding sandbox build failures The docker sandbox build in `integration_docker` has been failing every release since 0.22.3-release-7df5ac68. The build itself is fine; what fails is `npm run prepare:package` inside the Dockerfile's builder stage: Error: Prepared package unpacked size 101897869 bytes exceeds 100663296 bytes `assertPreparedPackageSize`'s 96 MiB budget was set in QwenLM#6691 when the prepared package was ~80.6 MiB. It has grown with ordinary feature work since — 96,802,417 bytes at 0.22.1, 98,582,313 at the 08-31 nightly, 101,897,869 now, with the OpenTUI migration batches carrying two UI stacks at once — and it crossed the ceiling. Raise the budget to 112 MiB, the same "headroom, not target" call QwenLM#6688 and QwenLM#6691 made before it. vendor/ripgrep (24 MiB, five platform binaries) and web-shell/assets (18 MiB, mostly shiki grammars, mermaid and cytoscape) are the two places worth trimming if we would rather bring the package down than keep raising the ceiling; that is a separate change. The reason a one-line size error cost a 20-minute release run to diagnose is the other half of this commit: - `build_sandbox.js` sent the image build's output to /dev/null unless VERBOSE was set, so the failure surfaced as an execSync stack trace with `stdout: null` and no way to tell what broke without rebuilding by hand. `e2e.yml` had already worked around this by setting VERBOSE; the release workflow had not. Now CI streams the output, and a quiet local build keeps it and prints the tail when the build fails. - Nothing ran `prepare:package` before the publish job, so its guards were first exercised by the Dockerfile — the slowest consumer in the pipeline. `quality_build` now runs bundle + prepare:package after uploading its build artifact, which reports the same failure in minutes without touching what downstream jobs consume. * fix(release): close sandbox output review gaps Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> --------- Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this PR does
Raises the prepared npm package size ceiling from 80 MB to 96 MB in the
prepare-package.jsrelease script. TheassertPreparedPackageSizecheck, introduced after v0.19.8, was set at 80 MB, but the current package is 80.58 MB — 597 KB over — which blocked the Docker sandbox build during the v0.19.9 release.Why it's needed
The size guard is a safety net to prevent accidentally shipping oversized packages, not a performance target. The package has grown naturally through feature additions (web-shell UI, expanded locales, additional CLI chunks) and is only marginally over the original estimate. Raising the limit to 96 MB provides ~19% headroom for future growth while still catching runaway size regressions.
Reviewer Test Plan
How to verify
npm run build && npm run bundle && npm run prepare:package— the prepare step should complete without the "Prepared package unpacked size … exceeds … bytes" error that previously occurred.npx vitest run scripts/tests/package-assets.test.js— all 16 tests should pass, including the oversize-budget test (which uses its own 50 KB limit, independent of the default).Evidence (Before & After)
Before:
After:
Tested on
Environment (optional)
Verified on Linux with
npm run build,npm run typecheck,npm run lint,npm run prepare:package, and focused Vitest runs.Risk & Scope
Linked Issues
Fixes #6687
中文说明
此 PR 的作用
将
prepare-package.js发布脚本中 npm 包解包大小的上限从 80 MB 提高到 96 MB。在 v0.19.8 之后引入的assertPreparedPackageSize检查设置为 80 MB，但当前包大小为 80.58 MB — 超出 597 KB — 导致 v0.19.9 发布时 Docker 沙箱构建失败。为什么需要
大小检查是一个安全网，用于防止意外发布过大的包，而不是性能目标。包大小通过功能添加（Web Shell UI、扩展的本地化、额外的 CLI 代码块）自然增长，仅略微超过最初的估计。将限制提高到 96 MB 为未来增长提供了约 19% 的余量，同时仍能捕获失控的大小回归。
审核者测试计划
如何验证
npm run build && npm run bundle && npm run prepare:package— prepare 步骤应完成，不再出现之前发生的"Prepared package unpacked size … exceeds … bytes"错误。npx vitest run scripts/tests/package-assets.test.js— 所有 16 个测试应通过，包括超预算测试（该测试使用自己的 50 KB 限制，与默认值无关）。证据（修复前与修复后）
修复前：
修复后：
测试环境
风险与范围
关联 Issue
修复 #6687