Repository navigation
Conversation
(ai: vllm-qwen/qwen3.8-27b) 查重:不重复。 已扫全部 open PR(含 #4750 存储冷加载、#4723/#4751 等近期内存/存储类修复)——没有第二条 PR 触碰 readBody 输入生命周期 / handleRequest 原始 Buffer 释放这条失败域。#4750 是存储冷加载(不同机制,PR 描述也已声明独立),#3437/#3643 讨论的是更宽的活跃请求物化面,均未实现本 PR 的输入生命周期清理。 标签: 开始按 PR Review 规范审:先读 #4753 与 diff 全量、核对既有行为清单,再本地定向验证,结论按结构化八问给出。 |
(ai: vllm-qwen/qwen3.8-27b) Review 结论:可合并① 方向审核(对照 #4753):#4753 点名的三个滞留点——readBody 的 listener/chunk 引用、转发后传给插件记账的 raw Buffer、overflow-refold 回调持有的 prepare 闭包——全部在根因处(生命周期管理)修掉,不是在出口层遮症状。边界划得也对:accepted outbound body(fake-completion/blind retry、echo provenance 要用的)与 session pin 生命周期原样保留,与 #4750 storage cold-load 正交。方向正确。 ② 回归审查(diff 触碰路径的既有行为逐项清点):
③ 代码审查:整洁达标——命名达意、注释讲为什么、无死代码/魔法数字/新依赖。 ④ 测试有效性:不是假测试,我实际做了 fail-on-old 验证——把三个新测试文件拷进 origin/master(bb7c249)worktree,全部按预期失败(readBody 取消测试因旧代码无 close handler 而挂起;新 API 缺失直接 import 失败);PR 分支上 16/16 绿;触碰改动函数的相邻套件(issue1307/2029/3400/plugin-fork/session-transient-memory)83/83 绿;typecheck 干净。断言有牙:trace 数组精确序列、release 恰好一次、stream-controller 在释放边界仍 pending 再完成的边界断言。 ⑤ diff 整洁度:7 文件 +423/-26,每一行都服务本 PR 目的,无跑题改动、无锁文件/生成物噪音。 CI:head 9c8c72c 最新 run 全绿(含 real codex e2e 与全部 e2e 车道)。过程中有一次红 run(storage-render golden 的 metadata 段漂移 ×4 wire),签名与 #4599 已列档的既有 born-red 集群同族,同 SHA 重跑即绿,且本 PR diff 不触碰那些路径——判为继承性/flake,非本 PR 引入。 八问
判定:ready-to-merge。 跨 4 个 src 模块,按 §7.4 属人审层,请人工合并。 |
The engineLane=server metadata added by f590da9 explains the entire drift: removing that one field reproduces the old metadata digest. Regeneration changes only metadata and the enclosing digest; all wire bodies, state, originals and statistics remain identical.
Compare unified reads with an independent envelope reader plus the documented migration. Persist alignment before rollback/corrupt-index checks, select legacy explicitly, and assert the recovered raw ID under its ledger ref. Keep checkpoint writes deterministic so sampled ingest cadence cannot change the seed between reader legs. All 28 targeted storage tests pass; no product migration or digest assertion is disabled.
Preserve both plugin compression routing and request wire metadata imports. Keep the request input release and readBody listener cleanup behavior intact. Reconcile storage tests with upstream's independent legacy oracle and citation-normalized migration checks. Retain pre-migration exact digests, rollback/corruption persistence, orphan restamp assertions, both fork storage modes, Windows store cleanup, and exact launcher argument checks. Validation: 28 request/metadata/readBody/concurrency/blog tests, 63 unchanged fork/orphan/launcher tests, 17 final golden/storage proof tests, TypeScript typecheck, and production build passed. Only targeted local suites were run.
Windows SIGTERM terminates the child instead of running its graceful shutdown handler. Trigger the existing loopback shutdown route on Windows so the draining-marker regression exercises the same lifecycle as POSIX. Wait for child close before deleting its database, destroy sockets owned by the silent TCP fixture, and stop health polling when the child exits. Keep both regression scenarios and their behavioral assertions intact. Validation: the isolated CI-preloaded serial test file passes 6/6 and exits naturally in 11.58 seconds; npm run typecheck and npm run build pass.
Windows CI can reset an aborted probe connection instead of ending it. The silent TCP fixture did not handle errors on accepted sockets, so ECONNRESET became an uncaught test exception after the probe finished. Destroy reset sockets and add a real resetAndDestroy regression against the same fixture. Keep the existing port-owner and ladder assertions. Validation: the new regression reproduces ECONNRESET before the fix; the isolated CI-preloaded serial test file then passes 7/7 and exits naturally. Pure tsc and git diff --check pass.
…eam conflict)
Single content conflict in tests/issue4982-draining-twin-ladder.test.ts resolved
by taking master's cross-platform POST /__bili/shutdown block (test#5050) while
keeping this branch's fixture improvements (killChild close-event+SIGKILL timer,
{close()} silent-TCP fixture, aborted-health-probe test) - union of both sides.
[bot] (ai: vllm-qwen/qwen3.8-27b) 上游冲突已解决,PR head 已更新。 把最新 master 合入 PR 分支(fast-forward、非强推),唯一一处内容冲突按「双方并集」处理,已推送到作者分支 结构化八问
一点提醒(供 review 留意,我未擅自改动):该 PR 分支当前在原单提交之外还累积了约 8 个先前 sync 会话的测试/合并提交(Windows 优雅关停、health-probe fixture、storage render-golden 等),超出了最初「input-lifetime」单提交的范围;它们已在远端,若要收敛需改写作者分支历史(强推),不在本次「解冲突」的职责之内,留给你判断是否需要单独整理。 收工判定:冲突已解、PR head 已指向 |
[bot] 🏷 (ai: vllm-qwen/qwen3.8-27b) 结果确认:PR #4756 的上游合并冲突已解决。
完整八问分析见上一条回复。待 CI 在新 head 上转绿后由你手动合并(Agent 不合并 PR)。另提醒:该分支在原单提交之外累积了约 8 个先前 sync 会话的测试/合并提交,超出最初范围,是否收敛留你判断。 |
(ai: vllm-qwen/qwen3.8-27b) Synced origin/master into |
(ai: vllm-qwen/qwen3.8-27b) CI 红了,但不是本 PR 的问题——是继承自 master 的 #5144「cold raw-tail fork」flaky test,我触发 rerun 后仍复现,任何 merge 都修不了。已按「非小修」路径升级处理,未改本 PR 分支一行代码。逐条回答:
为什么没开新的 decision-request issue / 为什么没在分支上修:CI 协调 owner policy(2026-10-24)明确「一切 CI 问题去 #4599、禁止为 CI 问题开新 issue」,且 #4599 已有同类决策以评论形式处置的先例;所以我把决策请求作为评论报到 #4599(含选项 + 推荐 + 移交哨兵),而不是另开 issue。修它需要 master/ci-fixes 侧工作,不属于本分支小修,故未 push。 收工判定:本 lane(attempt 2/2)到此为止——CI 红已定性为继承 flake 并移交 #4599 哨兵/owner;本 PR 无需改动,待 #4599 侧根因收敛(或 admin 放行)后即可绿。 |
# Conflicts: # tests/issue4982-draining-twin-ladder.test.ts # tests/plugin-fork.test.ts # tests/storage-orphan-recovery.test.ts
[bot] 🏷 (ai: vllm-qwen/qwen3.8-27b) Merge-guard sync done: merged origin/master through |
Fixes #4753.
Large requests retained their network chunks, raw Buffer, and preparation closure throughout long responses. This clears readBody's owned listeners/chunks on settlement, captures the raw-wire hash and comparability verdict before input mutation, and releases the raw/parsed input, affinity message alias, and preparation closure once overflow retries finish. Plugin bookkeeping still commits after forwarding.
Accepted outbound bodies remain available for fake-completion retries and echo provenance. Session pins and locking retain their existing lifetime. This is independent of the storage cold-load changes in #4750.
Validation:
No kernel, configuration, persistence-format, or version changes. No runtime deployment. This removes demonstrated unnecessary retention; it does not establish that every possible OOM path is eliminated, and prepared messages/outbound retry data still remain live as required.