Repository navigation
Conversation
…a frozen watermark Three root causes behind "session hangs / context keeps growing after a restart or model switch": 1. A plain prompt_cache_key is not plugin ownership. Only a real omp registration or a persisted pluginAgent may unwrap the |sub: namespace; otherwise instructions drift (model switch, async tool registration) forked the main conversation into an empty namespace whose compression state was gone, so every existing block was invalidated. 2. Existing conversation mappings now restore their original session and compression blocks instead of minting a fresh bare-id session. 3. A failed preflight freezes the original history BOUNDARY rather than the range worklist it happened to select: every successful fold changes which ranges stay viable, so replaying a stale worklist compressed nothing and the retry looked bigger. The walk now recomputes remaining viable ranges against that boundary after each fold, including the soft-protected recent zone under overflow, while turns appended during the failure window stay out of the compression input. # Conflicts: # CHANGELOG.md # src/plugin.ts # src/preflight.ts # src/server.ts
…eline wedges preflight The preflight trigger floors on session.stats.lastInputTokens. After an as-is forward under preflight (ranxianglei#300) the measured baseline can stay pinned above the window while the prepared payload itself fits (~127k against a 256000 window on a live session). Every turn then re-ran the fold walk on ranges the payload no longer needed: three 60s summarization attempts, structured 502 on upstream 500, dead-end cooldown, repeat. Forward as-is when a known-baseline session's payload estimate fits and its measured baseline sits above the window (ranxianglei#301: as-is is safe; the next usage report self-heals the baseline). Inside-window folding is untouched — the codex headroom target still walks fitting 90-100% payloads. # Conflicts: # CHANGELOG.md
[bot] 🏷 ## Review: PR #1004 (head Scope check. 本 PR 相对 master 含两个 commit:#1003 的 restart 修复( 代码审查(
测试审查( 本地验证(PR head
需要 owner 注意的事项(不阻塞代码本身):
结论:增量修复最小、打在根因上(stale floor 不该驱动 fold 决策,fitting payload 按 #301 先例直接转发并靠 usage 自愈),guard 边界(codex headroom、image hatch、anonymous、estimate-source baseline)全部核过无副作用,回归测试钉住了原症状。属于 preflight/wire 相邻行为变更 + fallback 策略产品决策,按 §7.4 需人工合并。#1003 先合 → rebase 解 AGENTS.md 单点冲突 → CI 绿后可合。 一句话中文摘要:核实了 PR #1004 —— 当 stale usage baseline 卡在窗口之上而真实 payload 其实 fit 时,preflight 跳过无效的 fold walk 直接 as-is 转发(下次 usage 上报自愈 baseline);guard 边界(codex headroom/image hatch/anonymous)无副作用,本机 typecheck+1952 项测试+build 全绿,待 #1003 先合、rebase 解一处 AGENTS.md 文档冲突、CI 转绿后即可合并。 |
|
pr没看到,只盯着issue列表了 你提交了几个pr,ework看有对应issue吗 没有的话帮忙建一下 本作者所有的pr都扫描一遍 |
[bot] 🏷 收到。正在扫描 |
[bot] 🏷 ## 扫描结果: 用 GitHub search API 扫了该作者在 ranxianglei/billion-context 的所有 PR(含已关闭):共 4 个,全部 open(今天 12:41–12:56Z 创建)。逐个核对 ework issue 列表:
结论:4 个 PR 全部有对应的 顺带提醒(影响合并顺序):这 4 个是一个 stack,必须按 #1003 → #1004 → #1006 → #1008 的顺序合,每合一个把下一个 rebase 上去;#1003 可以直接合我推的 rebased 镜像分支。另注意 #1006 的 一句话中文摘要:扫描了 asuan-dev 名下全部 4 个 PR(#1003/#1004/#1006/#1008,均 open),每个在 ework 都有对应的 [PR] issue、且都已被审完,无缺失、无需补建;它们是同一 stack,请按 1003→1004→1006→1008 顺序 rebase+合并。 |
问题
preflight 触发以
session.stats.lastInputTokens兜底,但早前 #300 的"as-is 转发"会把 baseline 钉在窗口之上。线上会话:257,613-token 兜底 vs 256,000 窗口,而真实 prepared payload 只有 ~127k — 每轮都重跑 fold walk:3 次 60s 非流式 summary(~3.4min 停顿)→ upstream 500 → 结构化 502 → 5 分钟 dead-end cooldown,循环往复。修复
src/server.ts:已知 baseline 的会话,payload 估算 fits window 而测量 baseline 停在窗口之上时,直接 as-is 转发(#301:as-is 是安全的,下一次 usage 上报会自愈 baseline)。窗口内 folding 逻辑不变 — codex headroom target 仍走 fitting 90-100% payload。验证
tests/preflight-fail-fast.test.ts:fitting payload + stale floor above window → 零 summary 调用,直接转发。typecheck clean。