Skip to content

[PR] chore: empty PR — trigger ci:full on master head (deep review carrier) - #4908

Open
ranxianglei wants to merge 9 commits into
masterfrom
2026-10-27_ci-full-empty
Open

[PR] chore: empty PR — trigger ci:full on master head (deep review carrier)#4908
ranxianglei wants to merge 9 commits into
masterfrom
2026-10-27_ci-full-empty

Conversation

@ranxianglei

@ranxianglei ranxianglei commented Oct 27, 2026

Copy link
Copy Markdown
Owner

(ai: zhipuai-lb/glm-5.3)

Empty-commit PR. Purpose:

  1. Run the full on-demand CI matrix (ci:full label) on the current master head (e4cc685).
  2. Carry the deep review of v0.1.208..master (585 commits, 439 files, +46K/−5.3K) — review findings will be posted as comments on this PR.

No code change. Do not merge; close after review + CI verdict.

@ranxianglei ranxianglei added the ci:full Run the FULL CI matrix (all e2e lanes + 12-leg test matrix) on this PR label Oct 27, 2026
@ranxianglei ranxianglei changed the title chore: empty PR — trigger ci:full on master head (deep review carrier) [PR] chore: empty PR — trigger ci:full on master head (deep review carrier) Oct 27, 2026
@github-actions

github-actions Bot commented Oct 27, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

📦 Built Package Artifact

Branch: 2026-10-27_ci-full-empty (1af19eb)

Latest build — install this exact version

npm install -g [email protected]

This exact version is immutable and reproducible. The rolling pr tag tracks the newest test build across all PRs.

Recent builds (commit → version)

commit version build
1af19eb [email protected] build
e74e6aa [email protected] build
a9cf26d [email protected] build
20bb2be [email protected] build
d051a04 [email protected] build
382797c [email protected] build
54c92cb [email protected] build
76a67bb [email protected] build

Download artifact

  1. Download the artifact from the Actions run
  2. Extract the tarball and install:
tar xzf billion-context-pr4908.tgz
npm install -g package

Install instructions are refreshed on each push.

This was referenced Oct 27, 2026
Closed
Closed
Closed
@ranxianglei

ranxianglei commented Oct 27, 2026

Copy link
Copy Markdown
Owner Author

(ai: zhipuai-lb/glm-5.3)

深度审查:v0.1.208 → master(585 个提交,439 个文件,+46K/−5.3K)

本 PR 是空提交,只承载两件事:① 用 ci:full 在当前 master 头(e4cc685)跑全量 CI;② 贴这份 v0.1.208 以来的全量深度审查。无代码改动,请勿合并,看完 CI 结论后关闭即可。

方法:4 路并行深审(存储引擎 / dsh 车道 / 缓存与快照渲染 / 其余管线)+ kernel 与 pi-subagents 由主审直接过;所有 P1/P2 级发现均回到源码逐行人工复核后才写进本报告;范围核对过 v0.1.208(carve-out 版,内容已全部包含于 master,经 #4708 回流)。

总体结论

没有发现 P1(崩溃 / 数据丢失 / 会话永久不可用 / 缓存击穿类)。 这个区间整体质量异常整齐:几乎每个 hunk 都带 issue 编号、写明故障模式和降级路径;dsh 车道这次修的恰恰是四个会话损坏/风暴类旧病(#4438 折叠态被误清、#3013 重试风暴、#4755 恢复放弃、#4811 busy 掉线)。下一个版本可以发,但有 3 个确认的 P2 建议先修(均为小改动,见下)。

P2 — 确认缺陷(已开 issue)

# 问题(人话) 位置 issue
1 fork 出来的子会话第一次保存会把统一存储里的血缘(父会话 id、fork 点 seq)清成 NULL——fork 本身能用,但索引里子会话变孤儿,导出/按链查询拿不到 fork 点 src/storage/store.ts:797-810(upsert 无条件覆盖)+ src/storage/ingest.ts:434-441(forkPointSeq 硬编码 null)+ 插件 fork 从不写 derivedFromSessionId(src/plugin.ts:1518-1519) #4910
2 MySQL 后端的 fork 行克隆和快照窗口读没接线——shadow.ts 只路由 SQLite,mysql.ts 里写好的同款实现零调用方;MySQL full-mode 用户的 fork 子会话转写为空,渲染车道永久走 legacy,静默功能缺口 src/storage/shadow.ts:830-836 等(this.sync === null 即返回空,从不走 this.backend);src/storage/mysql.ts:988-1042 死代码 #4911
3 opencode V2 降级直发路径:超 ~536MB 的 body 在「本地拒绝超窗请求」时解码抛 RangeError 逃出路由处理器——本该给宿主干净拒绝说明,变成未捕获异常;正是 #3128 放进来的多 GB 单请求类 src/agent/opencode-native.ts oversizeDirectRefusal:req.clone().arrayBuffer() 在 try 内,后面的 new TextDecoder().decode(body)(#4121 行)在 try 外;对照 src/agent/native-intercept.ts:583-586 同款在 try 内 #4912

分区结论

存储引擎(src/storage/ + persist.ts + session.ts,+~1.6K 行)

新增:打开即 quick_check 的完整性门(失败隔离 .corrupt-* 并从 JSON 信封恢复)、seq 账本(#4316:消息拿到持久 seq、冷加载一次性把引用号对齐到账本位、折叠块记录精确覆盖区间)、fork 行克隆、快照渲染的窗口化轻读。除上表 1/2 外,核对过引用计数事务(少计即抛、不会算成负数)、克隆回滚、迁移流式化(#4677)——干净。 值得留意的 P3:① 冷加载对齐中,内核先置 refLedgerAligned=true 再做内容库 re-key/令牌快照搬运,后半段若抛异常会留下「引用已改号但内容库还挂旧号」且永不重试(建议改顺序或快照回滚,src/persist.ts:1604-1666);② 老库遗留的 0/0 折叠块区间会被内核读者当成「真覆盖了 seq 0」(目前惰性无害,建议一次性迁移成 −1 哨兵);③ 完整性缓存在迁移前写入导致键立刻过期(纯浪费);④ 后台完整性扫描 worker 只在结束时 unref(),超大库扫描期间一次性进程退不出去。

dsh 车道(src/agent/dsh-*、hermes-plugin,+~1.5K 行)

这次是净修复区间:审阅车道隔离(#4438,修掉「引用策略原文的检查点被误判成压缩摘要→整个会话折叠态被清」的 P1 级旧病)、终局拒绝标记 bili_final(#3013,止住 5000 次重试锤)、自愈补全(#4755/#4811,BUSY 代理改为等 10s 再路由而不是掉线重撞)、msgids 全链路钉死(#4491,双端常量逐字一致已核)。未发现 P2。 P3 侧:hermes python 侧探活没有 TS 侧的 BUSY/DEAD 区分(sat-but-alive 会被当死掉引导出短暂直连窗口);native-ws-intercept.ts:412 用 === false 判 gate 而一个分支返回 Promise(当前不可达,共享状态隐患);hermes register() 异常路径的「保持沉默」日志与后台线程行为可能矛盾;一次请求等待预算(105s)小于最坏自举时长(~420s);copyText 兜底 textarea 的 ta.style = {...} 是无效赋值(对象赋给 style 不生效,兜底时会闪一个可见输入框)。

缓存 / 预检 / 快照渲染(cache-ledger、preflight、snapshot-render、codex-catalog-cache,+~1.1K 行)

两个疑似 P1 被主动攻击后排除:WS 增量渲染不会重复消息(前轮输入只活在转写行、尾巴只带回显输出);commitFold 的 TOCTOU 窗口在摘要等待后状态已变时会优雅丢弃而非抛异常。#4288 预检 fit-exit 重落地(按无下限的轮文本对折叠目标判,armed 基线例外保住 #1195 救援)在文本对文本、armed 例外、fit 抑制 stale 失败戳三个轴上都有测试钉。新增的 codex 目录离线缓存(6h TTL、401/403 墓碑、304 协商、16 条 LRU、凭据不落盘)测试是 #3617 纪律的范本(10 条含 4 条负向)。P3:① 预检的尾段 sub-min 反向合并没过它自己正向门那条「不跨覆盖边界」的检查(危害有限:内核会把已折叠 id 雕掉,只是摘要提示词里多带已折叠文本,但与注释自述矛盾);② D5-5 窗口读的「缺口→全量重载」安全网没有负向孪生测试;③ 渲染热路径上有 O(rows×covered) 的嵌套扫描(长会话纯性能问题,改 Map 即线性);④ ≥25% 尺度的外部 persona 结算可写走会话锚基线(主轮永远自愈,只造成基线摆动,建议写入侧 max 一下或加注释)。

其余管线(server/loop/agent/launcher,+~4K 行)

无 P1。除上表 3 外的观察项:① 压缩/解压全失败轮现在直接终止本轮(#4186,防缓存接缝,有意设计)——对爱犯错的模型单轮压缩成功率会降,恢复推迟到下一轮,建议在遥测里盯 [acp-loop] failed compress/decompress round … breaking early 的频率;② 降级直发的体积测量会把整个 body 物化成字符串(host 进程内 2-3× 内存尖峰,多百 MB 历史时 OOM 相邻);③ 世代边界注记(#4305)的 m\d{4,} 扫描会因用户正文里粘贴 ref 样文本而植入一条终身系统提示行(影响=一行+一次缓存扰动,建议限制扫描窗口或折叠后清除);④ 出站图片预算 shedding 与 429 调速器默认开启——429 调速按 origin+凭据持锁,同提供商的其他会话会跟着被本地拒 429(by design,注意 WS 车道不受它管的不对称);⑤ 无工具调用的纯聊天会话绕过成员资格门(当前 persona 都带工具 id,窗口很窄)。msgid 钉死、退化即降级的纪律在 opencode/pi 双端实现一致(#4516 重生、#4168 409 重绑、#3654 busy 诚实拒绝都验过干净)。

kernel(0.0.161 → 0.0.168,版本纪律 CI 强制,核过合法)

主线是 #4316 层3:折叠块只在能证明区间精确(直接消息全带 seq 戳、消费块全带界、并集恰好一段无洞)时才记 startSeq/endSeq,−1/−1 哨兵在两个读者处都正确判为「无主张」;引用在冷加载一次性对齐到账本位(restampRefsToLedger),换号映射保留在 superseded 表里让重启前发出的 compress 调用被诚实翻译或拒绝(src/stream.ts 已核);克隆/同步两处都补上了 refLedgerAligned 传递(#4797 修的就是漏传)。#4252 压缩工具 schema 收敛到单一字符串形式(golden 同步缩容,-1552 行,广告面收窄、解析面照收全部旧形态)——契约方向正确。pi-subagents 本区间零源码改动(只有 lockfile)。

其他

CI:bugfix-lane/backport 机器整体拆除(#4722/#4719),release-bugfix.yml 重写,ci:full 三层门控不变;plugins/codex 为全新市场分发文件(纯新增);hermes-plugin 独立评审见上。

CI 结论(全绿 ✅)

90 个 check run,每个同名 job 都有 success(cancelled 条目是重跑前的旧 run,不代表失败):

  • test 10 分片全绿:ubuntu-latest(node 22/24)× 各 3 分片 + windows-latest(node 22/24)× 各 5 分片;
  • static-gates 4 组合全绿(ubuntu/windows × node 22/24);
  • 8 个 gate 全绿;build-artifact 绿;
  • real-client 车道全绿:codex(URL+launcher 双模式)、dsh headless、opencode native、pi(codex-responses WS / package-native / OpenCode V2 WS)、hermetic registry e2e(ubuntu+windows);
  • 守卫全绿:kernel-guard / lane-guard / pi-subagents-guard / config-surface-guard / lifecycle-ledger-guard / lock-sync / version-guard / unused-exports / test-import-graph / docs-sync / docs-coverage / mysql-contract;
  • red-signal skipped(无触发条件,符合预期)。

即:当前 master 头 e4cc685 上,静态门、全量测试、全部真实客户端车道与发版守卫均通过——与审查结论「可发,建议先修 3 个 P2」相互印证。

审查执行:4 路并行 reviewer + 主审复核(所有 P1/P2 结论均人工回到源码确认);分区细节、验证过的干净面与完整 P3 清单在审查过程记录中,需要任何一条的展开可以直接问。

@ranxianglei

ranxianglei commented Oct 27, 2026

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b)

查重: 不适用——这是对既有载体 PR #4908 的收尾确认,不是新的缺陷报告。

收到线程两条未处理评论(深度审查正文 + github-actions 构建通知)。没有照搬审查自述,逐项实测核对了一遍:

  1. 空提交属实:分支 2026-10-27_ci-full-empty 在 master 头 e4cc6857 之上仅一个空提交(76a67bba),与 master 的 diff 为零行。
  2. CI 全绿:头提交上共 90 个 check run —— 54 success + 1 skipped(red-signal,无触发条件,符合预期)+ 35 cancelled(重跑前的旧 run),0 failure。
  3. 三个 P2 已立项且均为 open:The first save of a forked child session clears the lineage fields (parent_session_id / fork_point_seq) in unified stora | fork 子会话的第一次保存会清掉统一存储里的血缘字段(parent_session_id / fork_point_seq) #4910(fork 子会话首次保存清掉血缘字段)、The MySQL backend's fork clone/window read is not wired up: shadow only routes to SQLite, and the equivalent implementat | MySQL 后端的 fork 克隆/窗口读没接线:shadow 只路由 SQLite,mysql.ts 里的同款实现是死代码 #4911(MySQL 后端 fork 克隆/快照窗口读没接线)、opencode V2 fallback direct-send path: For oversized bodies >~536MB, string decoding within the over-window rejection lo | opencode V2 降级直发路径:>~536MB 的超大 body 在超窗拒绝逻辑里解码字符串抛 RangeError,逃出路由处理器 #4912(opencode V2 降级直发路径 ~536MB+ body 解码 RangeError 逃出路由处理器),与审查报告表格逐条对得上。
  4. github-actions[bot] 的构建产物通知是自动评论,无需处置。

结论:载体 PR 的两个目的都已达成——master 头 e4cc6857 上 ci:full 全量矩阵通过,深度审查(无 P1、3 个 P2 已立项)已贴出。本 PR 无代码改动、不需要合并,请看完后自行关闭(系统规则 agent 不能关单)。三个 P2 会在各自 issue 线程里继续推进。

@ranxianglei

ranxianglei commented Oct 27, 2026

Copy link
Copy Markdown
Owner Author

(ai: zhipuai-lb/glm-5.3)

全量更新风险审查:v0.1.207(上版)→ master c499b14

范围说明:v0.1.208 是 CI 修复 carve-out(不在 master 线上);master 自身版本仍是 0.1.207。因此本区间 v0.1.208..c499b145 = 下次发版将发布的全部内容:454 commits、451 文件、+49,425/−5,434。按模块分节,重点标注:新功能、行为变更、配置变动、已知风险。
深审结论(前一轮):无 P1;3 个 P2 已修(#4914/#4923/#4924 已合并);本轮增量审查(billing/blog 车道)结论在各节。

1. 存储引擎(本区间最大结构变化)

新功能/结构演进

行为变更

已知风险(P3,前轮深审)

  • 冷加载对齐半程失败不重试(persist.ts refLedgerAligned 先置位,后半抛异常→引用改号但内容库挂旧号,永久失配)。
  • 老库 0/0 折叠块区间被读者当「真覆盖 seq 0」(惰性无害,建议迁成 −1 哨兵)。
  • MySQL fork 幂等 COUNT 在事务外(并发重复 fork → PK 回滚 → kernel-only 降级,数据正确)。

2. 压缩管线 / preflight / loop

新功能

行为变更(重要)

3. 缓存 / 渲染 / 会话身份

新功能

行为变更

已知风险(P3):预检尾段 sub-min 反向合并不过「不跨覆盖边界」检查;D5-5 窗口读安全网缺负向孪生测试;渲染热路径 O(rows×covered) 嵌套扫描(长会话性能);≥25% 外部 persona 结算可写走会话锚基线(主轮自愈)。

4. dsh 车道

5. pi 车道

6. opencode 车道(含 V2)

7. codex 车道

8. 其他宿主

9. Web 面板 + billing(本轮增量深审)

面板

博客(#4906,本轮增量深审)

  • 新功能:GitHub master 拉取文章(匿名 contents API,UA+Accept,零凭据)+ 每小时自调度刷新链(单句柄单链防叠 + unref)+ 面板内渲染(escape-first markdown,链接协议白名单)+ oversize 预算(512KB 文/2MB 图/8MB 轮/200 文件,整轮 fail-soft 保留上次成功内容)+ dsh 设置面板博客 tab。

10. 网络 / 凭据 / 日志

11. CI / 发布

12. 配置面变动汇总(重点)

新增配置键(CONFIGURATION.md en/zh 已同步;env > file > default):

键 默认 说明
network.throttle429Enabled / ...BaseDelayMs / ...MaxDelayMs / ...MaxConsecutive true / 2000 / — / — 429 出站节流(#4204),BILI_THROTTLE_429* 同名 env
network.httpOutboundBytes 10 MiB HTTP 出站软字节预算(#3909),BILI_HTTP_OUTBOUND_BYTES
compress.minSummaryLength / maxSummaryLength / externalSummary.autoFoldTargetTokens — / — / overflow 目标一半 外部摘要上限与自动折叠目标(#3635/#3444)
billing(prices 表 + 覆盖) models.dev 目录 每模型 USD 计价(#4899)
storage.backend sqlite MySQL 网络后端(#4911),BILI_STORAGE_BACKEND
diagnostics.dump4xx / dumpBody / dumpReq off 4xx 诊断转储(BILI_DUMP_4XX),有字节上限
pi.inline / opencode.inline opt-in(默认关) in-process 引擎(BILI_PI_INLINE / BILI_OPENCODE_INLINE);注意 #4571 曾默认开后已 revert
rollout.features.pluginLaneServerHistory 渐进 服务端持有史(#4491)
dns / tls 节、retry.maxRetries、targetTimeoutMs/totalTimeoutMs — 网络/重试细分

新增 env:BILI_THROTTLE_429{,_BASE_DELAY_MS,_MAX_DELAY_MS,MAX_CONSECUTIVE}、BILI_HTTP_OUTBOUND_BYTES、BILI_CODEX_STATE_MODE(+CODEX_SQLITE_HOME)、BILI_PI_INLINE、BILI_OPENCODE_INLINE、BILI_INLINE_DEBUG、BILI_STORAGE_BACKEND、BILI_REPLAY_RETRY{BASE_MS,MAX}、BILI_ROLLOUT_PLUGIN_LANE_SERVER_HISTORY、BILI_DSH_MAX_TESTED_VERSION、BILI_DUMP_4XX、BILI_PROXY_KEEPALIVE_MAX_MS。

默认值/语义变化:429 节流默认开;出站图片按学习上限收敛(#4124);compress 工具单一字符串形式;maxContextLimit 文档化为「促早压缩」杠杆(#4007);billing 坏块整块大声拒绝(#155 纪律)。

13. 风险汇总(给风险 review 的速查表)

级别 条目 状态
P2(已修) #4910 fork 血缘首存被清 PR #4914 已合并
P2(已修) #4912 V2 降级直发 >~536MB RangeError 逃逸 PR #4923 + 7e7f65d 已合并
P2(已修) #4911 MySQL fork 克隆死代码未接线 + DDL 分歧 PR #4924 + edc2185 已合并
P2(待裁决) billing 面板省钱额实时路径 w=input 价(应 cacheWrite),两面打架 需 owner 一句话定夺,修复一行
P2(待修) 博客详情路由正则不放行非 ASCII/编码 slug → 点文章落总览(client.ts:4324 vs blogfeed.ts:273) 一行修(放宽正则对齐 sessions 路由)
P2(待裁决) 远端 SVG 同源直出无 sandbox/nosniff → 坏合并即面板源 XSS(blogfeed.ts:531-535) 需 owner 裁定信任模型;建议无论如何加防御头(零成本)
P3 博客:大小上限后检(先整包入 RAM)、blogCache 无 TTL(常驻面板不刷新)、offline 文案误导、刷新链缺 reject 免疫 gate 已记录
P3 存储冷加载对齐半程失败不重试;0/0 区间当真覆盖;MySQL COUNT 事务外 已在 #4908 评论记录
P3 dsh hermes 探活无 BUSY/DEAD 区分;等待预算 < 最坏自举 已记录
P3 缓存:sub-min 反合并边界检查;D5-5 负向孪生缺失;渲染 O(rows×covered);外部 persona 结算基线摆动 已记录
P3 管线:#4186 全失败轮终止的观测;降级直发体积测量内存尖峰;世代边界注记误植;无工具纯聊天绕过成员资格门 已记录
行为面 compress 单字符串形式(破坏性,工具调用方需适配);429 节流默认开;图片出站收敛;一次性存储迁移 见上文各节

附:博客车道干净面(审查结论)

刷新链单句柄单链防叠(armSchedule gate)+ unref;5s 双计时超时;目录/资产路径穿越双门(404 在远端查询前);出站仅 UA+Accept 零凭据;markdown escape-first(script 渲染为转义文本,链接协议白名单+noopener);manifest 损坏 JSON 降级不失败;预算整轮 fail-soft 保留上次成功内容;纪律面(console/as any/@ts-ignore/文档同步)全绿。

This was referenced Oct 27, 2026
Closed
Closed
Closed
@ranxianglei

ranxianglei commented Oct 27, 2026

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b) Merged origin/master (c499b14) into branch 2026-10-27_ci-full-empty cleanly (no conflicts) → new head 54c92cb; PR now mergeable=true / in sync with master, ci:full running (28 checks queued/in-progress on new head).

@ranxianglei

ranxianglei commented Oct 27, 2026

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b)

出站查重:本轮风险评审的三处 P2 均已有现成 issue 与 PR(glm-5.3 评审后已立项),未重复立项、未并列开 PR——本轮做的是独立审核 + 补测 + 决策请求。

逐项状态:

1. 博客 slug 路由(#4957 → PR #4961):机制独立确认(src/web/client.ts:4323 路由正则窄于文件名派生 slug 的实际字符集,而 :940 链接生成全量编码)。PR 逐行审过:方向正确(放宽路由而非收窄生成侧)、回归清单干净(ASCII 子集不变 / 空 hash 仍落 overview / query-hash 行为不受影响)、测试双向有牙。结论:可合。CI head 33d2ba7c0:已跑 lane 全 success/skipped,0 failure。

2. SVG 同源直出(#4958 → PR #4962):机制独立确认并补一层事实——当前渲染下 markdown 图片只产生 <img>(src/web/markdown.ts:21 URL 白名单),SVG 脚本当前不可执行;属纵深防御而非活跃漏洞止血,p2 定级合理。PR 审过:双路径覆盖完整、行为变更 old→new 披露合规(no-cache 为既有值,实际新增是 sandbox/nosniff;svg→404)。发现缺口:原 PR 缺「refresh 轮次不下载 svg」的负向 pin(#3617 gate 纪律,gate 活在 src/web/blog-refresh.ts:220)——已补上并 push(a846f4f75;mock router 故意对 svg 返回 200 防断言恒真;本地 web-blog-refresh 18/18、web-blogfeed 10/10、typecheck clean)。结论:可合。

3. 计费 w=input(#4956,尚无 PR):独立判定 slip(契约误实现),建议走修复路径,详证已发 #4956 评论:registry.ts kernel-contract 注释(w = cache-write 价)+ CONFIGURATION.md:1577 文档口径 + finalize() 专门 cacheWrite 字段 + stamped 路径正确用 cache_write——四证同向;i18n "input−read delta" 文案本身也是 slip 证据,修时要一并改。issue 里顺带问的 RATIO override 张力:确认是连贯设计,不是缺陷。等 owner 拍板,拍板前不动手。

标签清理(mirror + GitHub 两侧同步):#4957/#4958 移除 dsh(panel 全局功能,非 dsh 车道专属);#4958 补 bug,并把 mirror 侧异常出现的 p1 归一回 p2(独立评估:潜在风险面且当前不可利用,不达 p1 标准);#4956 标签维持原样(bug/p2/review中/scope/ui)。

八问:

  1. 是什么问题:master 全量风险评审新发现的三处 P2(panel 博客链接不可达 / SVG 资产隔离缺失 / 计费面板取价错误)需要审核处置。
  2. 什么原因:① 路由正则与 slug 字符集两侧从未对齐;② 资产白名单建立时把 SVG 当普通图片类型,响应无隔离头;③ live 计费路径取 input 价而非契约定义的 cache-write 价。
  3. 影响范围与严重程度:均为 panel 展示面,核心压缩链路不受影响。① 非 ASCII/点号文件名的文章打不开,有绕行(p2);② 潜在安全面,当前 <img>-only 渲染下不可利用(p2);③ 节省额显示系统性偏高(fixture 价下 (w−r)·T 项 2.7→3.45),与缓存报告互相矛盾(p2,等拍板)。
  4. 怎么修复:① 路由正则放宽为 (.+)(与 sessions 路由一致,[PR] fix: panel blog detail route accepts encoded non-ASCII and dotted slugs #4961);② svg 移出白名单 + 其余资产加 sandbox/nosniff([PR] fix(#4958): stop serving SVG same-origin from the panel; sandbox all blog asset responses #4962,已补负向 pin);③ live 路径改取 cacheWrite ?? input + 更新三处测试 pin + i18n 文案(The "How Much You Saved" panel computes replay cost using the input price rather than the cache write price, resulting i | 面板「省了多少钱」按输入价而非缓存写价算回放成本,数字系统性偏高、与缓存报告互相矛盾 #4956,待拍板)。
  5. 是否有回归:① 无(三项既有行为清点在 review 评论);② svg 链接失效 = 有意变更已披露,仓库现存零 bundled svg;③ 修复后显示值回到契约值 = 有意,已披露数字影响。高危模式(fail-fast 变吞错/阈值漂移/输出格式变化)逐项过:无命中。
  6. 是否破坏缓存:不涉及会话/前缀缓存、重试与去重策略;[PR] fix(#4958): stop serving SVG same-origin from the panel; sandbox all blog asset responses #4962 的 no-cache 为既有值未变。
  7. 是否改了设计方向:未改。
  8. 是否引入新配置:无。重新启用 svg 需 owner 明确批准(代码注释已注明)。

收工判定:#4961、#4962 就绪待 owner 合并;#4956 待 owner 在「修复 vs 文档化为有意设计」间拍板,我的建议是修复。本载体 PR 使命已完成,关闭请 owner 操作。

@ranxianglei ranxianglei mentioned this pull request Oct 27, 2026
Merged
lamardealmaker pushed a commit to lamardealmaker/billion-context that referenced this pull request Oct 27, 2026
@ranxianglei
fix: blog panel P3 polish — content-length precheck, background refre…
9d474be 
…sh gate, 1h cache TTL, neutral offline wording

Four small defects from the ranxianglei#4906/ranxianglei#4908 deep review (P3 batch):

- web/blog-refresh.ts: getText/getImage now precheck a declared
  content-length header against their size budgets BEFORE reading the
  body, so a hostile/lying header cannot force a 512KB text or 2MB
  image download (the post-read checks stay as the authority when the
  header is absent or lies small).
- web/blog-refresh.ts: the fire-and-forget launchers (kickBlogRefresh,
  runBlogRefreshRound) wrap their round promise in a rejection-immune
  settle gate (settleRoundImmune) — an unexpected rejection inside a
  background TTL/coalesce round can no longer leak an
  unhandledRejection and kill the host process.
- web/client.ts: the blog view cache now carries a timestamp and goes
  stale after ~1h (matching the bl.sub promise of hourly turnover);
  a stale hit still paints instantly and re-pulls silently in the
  background, re-rendering only if the blog view is still on screen.
- web/i18n.ts: bl.offline no longer claims 'GitHub unreachable' — the
  server cannot know that; it now says the last refresh did not
  finish and cached content is shown (en+zh).

Tests: tests/web-blog-refresh.test.ts pins all four (body-spy proves
the precheck trips before arrayBuffer(); process-level unhandledRejection
listener proves the gate swallows a rejecting base; TTL boundary at
exactly 1h; wording pins en+zh).

Refs ranxianglei#4957 (blog route audit trail); review thread:
ranxianglei#4908
@ranxianglei

ranxianglei commented Oct 27, 2026

Copy link
Copy Markdown
Owner Author

opencode的inline模式默认被打开了吗 应恢复默认值

@ranxianglei

ranxianglei commented Oct 27, 2026

Copy link
Copy Markdown
Owner Author

(ai: zhipuai-lb/glm-5.3)

勘误(存储引擎分区 P3 ①):上面报告里写「内核先置 refLedgerAligned=true 再做内容库 re-key…且永不重试」——复核 master 现码(src/persist.ts 冷加载对齐块),实际顺序是引用改号 → 内容库 re-key → 令牌快照搬运 → 最后才置 refLedgerAligned=true,整段在 try 内,异常走 catch 记 warn 吞掉,flag 保持 false,每次冷加载都会重试,并非"永不重试"。真实残余风险应表述为:引用改号发生在 re-key 之前且不做回滚,若 re-key 抛异常且该会话随后被常规保存落盘,会留下「引用新号、内容库旧号」的半对齐内存状态被持久化;触发面窄(restampContentStore 需在特定形状下抛异常),后果是被改号消息渲染/解压拿不到内容(局部),不是数据损坏扩散。严重度维持 P3。

@ranxianglei

ranxianglei commented Oct 27, 2026

Copy link
Copy Markdown
Owner Author

(ai: zhipuai-lb/glm-5.3)

回归风险评估(v0.1.208 → master,存储引擎):结论——回归风险低,可以发版。逐层依据:

  1. 老会话(无账本)→ 新代码:主升级路径有专测钉死——tests/seq-ledger-pr3.test.ts S15 用旧格式夹具验证「冷加载把 legacy 计数引用一次性对齐到 seq+1,恰好一次」(4 项)+ tests/issue3573-cold-load-diagnostics.test.ts(3 项)+ golden storage-render 三线夹具。改号是幂等的一次性迁移,superseded/blocked 出口齐全。
  2. 已发现的两个回归类 bug 在发版前已修:The first save of a forked child session clears the lineage fields (parent_session_id / fork_point_seq) in unified stora | fork 子会话的第一次保存会清掉统一存储里的血缘字段(parent_session_id / fork_point_seq) #4910(fork 子会话首存清血缘,典型新路径回归)→ [PR] fix(storage): keep fork lineage when the child session is first ingested #4914 已合并;The MySQL backend's fork clone/window read is not wired up: shadow only routes to SQLite, and the equivalent implementat | MySQL 后端的 fork 克隆/窗口读没接线:shadow 只路由 SQLite,mysql.ts 里的同款实现是死代码 #4911+[PR] fix: route the fork lane through the network storage backend (#4911) #4924(MySQL 死代码接线,含我修的 DDL 默认值分歧)已合并。CI 全矩阵(90 check runs,含 SQLite+MySQL 双车道存储契约、真实客户端 e2e)在合并头全绿。
  3. 残余回归面(全部窄触发、局部后果、有降级):
    • 老库折叠块 0/0 区间 × 新精确区间读者(P3,惰性无害,无迁移)——最值得补一条「老格式会话→新版本→折叠/解压」e2e;
    • 潜伏损坏老库 × 完整性门:隔离是复制非删除(.corrupt-*),信封恢复 vs 全丢是净改善,但信封旧会丢最近历史(有感知差异);
    • MySQL fork 克隆死代码首次上产线(有契约测试,但"首次真实执行"值得发版后盯 mysql-contract 与真实用户反馈);
    • 冷加载对齐异常窗口(P3,可重试、局部)。

发版后监控三个信号:[persist] ledger-aligned refs vs alignment skipped 日志比例(skipped 多=异常)、.corrupt-* 出现频率、mysql-contract 车道。

@ranxianglei

ranxianglei commented Oct 27, 2026

Copy link
Copy Markdown
Owner Author

(ai: zhipuai-lb/glm-5.3)

存储引擎到底改了啥(v0.1.208 → master,10 文件 +1563/−94,50 个提交)——一句话:从「会话 JSON 文件 + 每次内存重建」升级为「SQL 统一存储 + 稳定 seq 账本 + 自愈完整性门」,为快照渲染(#3756)和精确媒体计费打地基。注意 STORAGE_SCHEMA_VERSION 仍是 8——没有破坏性 schema 迁移,全是加表/加列(带默认值 + 幂等 ALTER)。

七块内容:

  1. seq 账本(After model switch / client-side history rewrite, all message identities (content hashes) are replaced: ACP numbers re-m | 切模型/客户端重写历史后,消息身份(内容哈希)全部更换:acp 编号重铸、折叠覆盖大规模重挂、死 ref、churn 区临时膨胀重折 #4316)——每条消息入库拿稳定递增 seq,按 identity 去重;ingest 幂等可续传(ingestWatermark/tailSeqs/probeIngestBoundary/headRowMsgId,store.ts:1287-1386)。老会话冷加载时把旧计数引用一次性对齐到账本位(restampRefsToLedger,src/persist.ts,幂等,superseded/blocked 出口齐全,S15 专测)。
  2. 折叠覆盖区间精确化——折叠块记录精确覆盖的 seq 范围(min/max),覆盖审计不再靠顺序猜;这是 0/0 旧块 P3 的来源(老块没记区间,读者按惰性处理)。
  3. fork 行克隆 + 血缘——sessions 表加 parent_session_id/fork_point_seq,cloneSessionRows 在 SQLite/MySQL([PR] fix: route the fork lane through the network storage backend (#4911) #4924 接线)按行复制消息;失败降级 kernel-only fork。血缘首存被清的 bug 即 The first save of a forked child session clears the lineage fields (parent_session_id / fork_point_seq) in unified stora | fork 子会话的第一次保存会清掉统一存储里的血缘字段(parent_session_id / fork_point_seq) #4910/[PR] fix(storage): keep fork lineage when the child session is first ingested #4914(已修)。
  4. 完整性门(新文件 integrity-check.ts,269 行)——打开库跑 quick_check(512MiB 库约几秒),结果缓存到非 .json 边车(不污染信封目录);失败→隔离成 .corrupt-*(复制不删除)+ 从 JSON 信封恢复。把「存储坏了→整库不可用」变成「自动隔离+恢复」。
  5. 快照渲染窗口读——messagesForIds/uncoveredRows/messageIdRows(store.ts:1388+):按需只读未覆盖的行,不整会话重放;这是快照渲染引擎(Snapshot rendering: proxy-lane outbound is now rendered authoritatively server-side; existing sessions are immune to ker | 快照渲染:proxy 车道出站从服务端正史渲染,存量会话对内核升级免疫(#3752 根治) #3756,D 车道)的存储侧。
  6. 媒体字节入库——新表 message_media(session_id, seq, media_hash)(schema.ts:261):图片等媒体按 hash 进 content 库,计费面板按行查出真实媒体字节(替代纯估算,The "How Much You Saved" panel computes replay cost using the input price rather than the cache write price, resulting i | 面板「省了多少钱」按输入价而非缓存写价算回放成本,数字系统性偏高、与缓存报告互相矛盾 #4956 的地基)。
  7. MySQL 对齐与加固(mysql.ts +482)——五个 json 列补 DEFAULT ('{}')([PR] fix: route the fork lane through the network storage backend (#4911) #4924 我修的 DDL 分歧)、幂等 ALTER TABLE(messages.identity/retired_at)、shadow.ts 异步通道(lastLiveSeqAsync/cloneSessionRowsAsync);内容库 refcount 减计数加 AND refcount > 0 地板,已损坏的账本不会再减成负数(schema.ts)。

@ranxianglei

ranxianglei commented Oct 27, 2026

Copy link
Copy Markdown
Owner Author

(ai: zhipuai-lb/glm-5.3)

双写分叉风险评估(存储引擎,回应「降级反而是最危险的」)——结论:这个失败类真实存在(仓库踩过),但 v0.1.208→master 的方向是关分叉,不是开降级。默认用户根本不进双写(BILI_STORAGE_UNIFIED 是 opt-in,默认 legacy JSON 单写)。

已经踩过的坑(正是「降级→旧代被当真相→二者不一致」):2026-10-22 事故(#4323):多写者共享 sessions 目录时,漂移锁存无条件信「信封是更新的一份」,结果信封 12 个活跃折叠块 vs 索引 16——把旧代折半状态端给了用户,240K 已折叠令牌回灌上下文,重放全展开,preflight 死在 8.29M 幻影令牌上。

这条升级行加上的四道防线:

  1. 永不存在「两边都没写」的窗口(persist.ts:390-393):jsonWriterOff 需要显式关 + full 模式同时成立;sidecar 3 连败自禁后下一次保存立刻恢复文件写;禁用瞬间那笔保存甚至同步落一次 JSON 写(Storage Subsystem Wrap-up Checklist (#3130 Review): Dropping the last tick upon self-disable; BILI_PERSIST=0 falsely triggering a "Storage Degraded" banner; storageMode stamp mismatched with the actual enabled mode; and 3 more (6 items total) | 存储子系统收尾清单… #3135 ①:「该会话此刻在两边都不存在」)。
  2. 冷加载新鲜度仲裁([Bug][storage] Retained orphan originals freeze unified session ingestion; cold loads restore hours-old state #4216/Cold loads keep serving an index frozen by pre-#4249 orphan-skipped ingests #4370,persist.ts:1506-1525):full 模式每次冷加载探一次信封,按进度(requests 计数,平手比 nextBlockId)仲裁——「严格领先的信封只可能是新一代,不可能是回滚」;信封领先→从信封恢复并重导入索引。sidecar 禁用导致索引落后于信封的场景,重启即被这个探针治愈。
  3. 漂移锁存不再盲信信封(After idling for one hour, the fold override is lost: the client resends byte-for-byte identical content, and the previo | 闲置一小时后折叠覆盖丢失:客户端重发逐字节不变,已折叠的 ~240K token 内容自己回到上下文 #4323):改按折叠进度/映射 ref 数取「更完整的一侧」,平手才留历史偏好的信封。
  4. 隔离不销毁(Storage Reliability Trio: open-time self-check (quick_check) + online backup (VACUUM INTO) + second-process probe on the | 存储可靠性三件套:开库自检 quick_check + 在线备份 VACUUM INTO + 同库第二进程探测 #4175/[Bug] 0.1.205+: open-time quick_check is O(index.db) — 14 GB takes 260 s, so the 60 s spawn budget always kills the child and the host stays on direct | 0.1.205+ 开库 quick_check 使启动变成 O(库大小)：14GB 库 260 秒 → 必超 60 秒 spawn 预算 → 整生命周期直连 #4609):库损坏→.corrupt-* 复制隔离+重开干净库,信封仍是恢复源;原数据在隔离副本里。

剩余两个真实缺口(窄,已知):

@ranxianglei

ranxianglei commented Oct 27, 2026

Copy link
Copy Markdown
Owner Author

(ai: zhipuai-lb/glm-5.3)

勘误(上一条「双写分叉风险」评论):里面说「默认用户根本不进双写(BILI_STORAGE_UNIFIED 是 opt-in,默认 legacy JSON 单写)」——错了。核对 src/knobs.ts resolveStorageMode:env/file 都未设置时默认返回 "full",且这个默认在 v0.1.208 之前就已翻转(ec56adc,2026-10-19,#3818)——即上一版起默认用户就运行在统一存储 full 模式(双写:信封照写 + unified-first 读)。因此上面列的四道分叉防线(冷加载新鲜度仲裁、#3135 ① 同步落盘、#4323 折叠进度仲裁、#4175 隔离恢复)对默认用户就是活代码,不是 opt-in 用户的专属。结论不变(防线在这版加强),但「默认无此风险」一句作废。

@ranxianglei

ranxianglei commented Oct 27, 2026

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b)

更正成立——我按 triage 纪律在代码与 tag 层面独立复核了一遍，默认用户确实跑在 full 双写模式上。两点精度补充：

  1. 翻转点比「v0.1.208 之前」更早：逐个发布 tag 核对 resolveStorageMode——v0.1.202（10-19）仍是 return "shadow"，v0.1.203（10-21）起已是 return "full"，v0.1.204–v0.1.208 全部为 full；当前 master 同样在 env/file 双缺省时返回 "full"（src/knobs.ts:853）。即不是「上一版起」，而是已连续六个发布版运行在新默认下——针对 fork 窗口的四道防线对默认用户是活代码这一结论成立，且实际生效时间比更正里说的还早。
  2. SHA 引用：ec56adc9 是分支的 pre-rebase 状态（不是任何 tag 或 master 的祖先提交）；翻转实际经 merge commit fc15b1e（PR [PR] storage: default unified mode flips to full + six #3135 cleanups (#3818) #3819 / issue Storage wrap-up: 6 fixes + switch default mode to full (single PR) | 存储收尾六修 + 缺省模式翻 full(一个 PR 统一处理) #3818，2026-10-19）进入 master。内容一致，仅引用位置略有出入。

模式级语义也复核过：full = index.db 作为读取路径（unified-first、legacy 兜底）且 legacy 文件继续写入（src/storage/shadow.ts:263），与更正描述一致。结论：默认路径上的「双写分叉」担忧不成立；残余风险仅在显式配置 legacy/shadow/非法值的用户侧，与更正的表述吻合。

@ranxianglei

ranxianglei commented Oct 27, 2026

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b)

已把 origin/master（9b6ec2345，含 #4904 direct-window-guard 等 +5 commits）合入本分支并推送 → head d051a04；PR 状态 open / mergeable / blocked（checks running，仅新 head 在跑）。

@ranxianglei

ranxianglei commented Oct 27, 2026

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b)

@ranxianglei opencode inline 模式当前 master 上没有默认打开——但你的怀疑有依据，它确实短暂地以「默认开」形态上过 master：

现码核对（src/agent/opencode-native.ts:115-125）：BILI_OPENCODE_INLINE 与 "opencode":{"inline":true} 都未设置时走 attach > spawn，默认即旧行为。代码侧无需再恢复。如果你在自己环境里观察到 inline 行为，排查三处：shell/profile 里残留的 BILI_OPENCODE_INLINE、~/.config/billion-context/billion-context.json 里的 "opencode":{"inline":true}、以及是否用的 bili opencode-inline 启动（该子命令会显式置 BILI_OPENCODE_INLINE=1）。

@ranxianglei

ranxianglei commented Oct 27, 2026

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b)

P3 ① 勘误复核：顺序与 catch 语义部分核实无误，但「flag 保持 false、每次冷加载都会重试」这半句需要再勘误——真实情况分两个失败窗口：

窗口 A：异常发生在 restampRefsToLedger 的 pass 内部。kernel 全程在 scratch 副本上计算、整体通过才 swap（kernel/src/refs.ts:232-236 注释原文：「a mid-way failure must not leave a half-renumbered map」，swap 在 refs.ts:284）。此时 messageRefs 未动、flag 未置位 → 下次冷加载确实重试。勘误在这个窗口成立。

窗口 B：restampRefsToLedger 已返回（swap 已提交），其后的步骤抛异常——内容库 re-key（src/persist.ts:1624 restampContentStore）或 token 快照搬运（persist.ts:1644-1659）。关键事实：flag 不是在 persist 块末尾才生效的——restampRefsToLedger 自身在 commit 时就置了 state.refLedgerAligned = true（kernel/src/refs.ts:285），persist.ts:1660 只是冗余重设。于是 catch（persist.ts:1663-1667，warn 吞掉）之后，guard（persist.ts:1606）在此后所有冷加载直接短路——不再重试；且 flag 随状态持久化、hydration 带回（src/state-hydration.ts:41）、sync clone 刻意携带（kernel/src/sync.ts:106-110），全仓无任何路径清它。「引用新号、内容库旧号」的半对齐态从此对该会话状态永久成立。

即原报告「内核先置 refLedgerAligned=true 再做内容库 re-key…且永不重试」在窗口 B 是准确的，勘误把它整体翻成「总是重试」属于过度更正。

后果面（两版一致，维持局部）：被改号消息经新号 retrieve/decompress 取不到内容；plugin fork 一致性门（byRaw[entry.rawId]===ref）可能拒该会话 fork 快照。触发面比勘误所述更窄：restampContentStore 是纯对象操作（kernel/src/content-store.ts:136-168，迭代+spread，正常数据无可抛点）。严重度我倾向 P3 偏下或 P4：现实可达性近乎零，但「永不重试」的永久性比「可重试」加重一档，相抵后略降。

修法若要做是一行级：persist.ts catch 块里清掉 state.refLedgerAligned 重新武装（窗口 A 无害，窗口 B 获得重试——下次冷加载 refs 收敛为 kept、store 按 rawId 重键自愈）。已查 open/closed issue 无覆盖此子缺陷的条目；本 PR 是 agent 开的 deep-review carrier，是否立项/顺手修请 owner 定，我可以接。

另注：上面 14:43 「双写分叉风险评估」中「BILI_STORAGE_UNIFIED 是 opt-in，默认 legacy JSON 单写」的前提已被存储默认翻转推翻（默认自 v0.1.203 起为 full，见我此前对另一条勘误的复核）——该帖四道防线分析不受影响，但「默认用户根本不进双写」一句不成立。

@ranxianglei

ranxianglei commented Oct 27, 2026

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b)

独立抽查了这条评估里的具体断言（当前 master head）：

一处需要更正：残余面第 4 条「冷加载对齐异常窗口（P3，可重试、局部）」的「可重试」不成立。按我在 P3① 勘误复核里贴的两个失败窗口：窗口 A（restamp pass 内部抛异常）确实每次冷加载重试；但窗口 B（ref swap 已提交之后、内容库 re-key 或 token 快照搬运抛异常）不可重试——flag 在 kernel/src/refs.ts:285 随 swap 一起置位，catch 吞掉后 guard（src/persist.ts:1606）永久短路，全仓无清 flag 路径，hydration/sync 都只带回不清空。「引用新号、内容库旧号」的半对齐态对该会话状态永久成立。

发版风险评级不受影响（窗口 B 触发面近乎零：restampContentStore 是纯对象操作，正常数据无可抛点），但发版后监控清单建议补一条语义：ref/ledger alignment skipped 日志不是「偶发、下次自愈」的噪音——出现即代表该会话已处于永久半对齐（受影响消息的内容检索/解压持续 miss，fork 一致性门可能拒快照），直到新会话或手动干预。所以这个信号哪怕非零也值得逐会话排查，而不是只看比例。

@ranxianglei

ranxianglei commented Oct 27, 2026

Copy link
Copy Markdown
Owner Author

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b)

本轮工作小结（#4908 deep-review carrier）：

  1. 分支同步：origin/master（9b6ec2345，含 [PR] fix(#4894): arm the direct-fallback oversize guard on dsh not-ready sends #4904）合入本分支 → head d051a04，已推送，CI 在新 head 上运行。
  2. owner 提问：opencode inline 模式当前 master 未默认打开——10-25 移植期曾短暂默认开约 2.5h（2a7d6a97f），同日按 [PR] pi/opencode inline changed to manual opt-in: revert the default flip; default behavior is identical to the previous vers | pi/opencode inline 改为手动开启:收回默认翻转,默认行为与旧版完全一致 #4687 决定改回 OPT-IN（fd50e76fb），两个提交都不在任何 release tag，npm 从未发过该状态；代码侧无需恢复。
  3. 存储引擎各评估帖的独立复核（逐条对照现码，结论已分别回帖）：
  4. 待 owner 决策：窗口 B 子缺陷是否立项——修法一行级（persist.ts catch 里清 refLedgerAligned 重新武装），说一声我就接。

This branch has not been deployed

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

Reviewers

No reviews

Assignees

No one assigned

Labels

ci:full Run the FULL CI matrix (all e2e lanes + 12-leg test matrix) on this PR review中

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@ranxianglei