[Bug] 会话格式迁移后 dsh_session_log 水位失效：每次请求重发整份日志 → 413 且永久卡死

[strauss49]

Summary

会话格式迁移（V3 → V4）后，session-log-deepseek 不再认可迁移前写入的交付水位，导致每次请求都附带整份会话日志（dsh_session_log）。日志较大的会话因此超出 endpoint 的请求体上限并收到 HTTP 413；而失败又导致无法写入新的 delivery-accepted，于是该会话永久卡死，重试无效。

English summary: after a session-format migration the dsh_session_log watermarks written under the previous format generation are all skipped, so afterSeq falls back to -1 and every request re-sends the entire session log. For long sessions the body exceeds the provider's request-body limit → HTTP 413, and because no new acceptance can be written the session is permanently stuck.

Reproduction

1. 准备一个长会话（日志数十 MB，仍为 V3 代际）。
2. 升级到 SESSION_FORMAT_VERSION = 4 的构建后打开该会话（日志按设计迁移为 V4，原代际文件保留）。
3. 发送任意消息 —— 哪怕只有一个词。

稳定复现：DeepSeek Messages request failed (413)，code: INVALID_REQUEST，status: 413。与消息内容、大小无关（"ping" 同样失败）。

Current behavior

每个请求都携带完整日志。用本地转发代理抓到的真实请求体（dsh 0.1.7-alpha.2；会话 29,290 事件，解压后日志 84.9 MB）：

dsh_session_log : 99,602,061 B (94.99 MB)   // afterSeq: -1, throughSeq: 29304, events: 29305
messages        :  1,551,364 B (1.48 MB)
tools           :     28,588 B
system          :      7,876 B
plugins         :     12,097 B
→ 请求体合计 96.5 MB → HTTP 413

把该附加项关闭后，同一会话、同一条消息：请求体 1.53 MB → HTTP 200，正常作答。

endpoint 体积上限实测（https://api.deepseek.com/anthropic/v1/messages，以无效 body 探测：超限 → 413，未超限 → 422，两种情况都不消耗 token）：8 / 16 / 24 / 32 MB 通过，48 MB → 413。即任何日志接近 ~48 MB 的会话在格式迁移后都会永久不可用；日志较小的会话会先付出一次超大上传，之后恢复增量。

上下文本身是健康的，可排除"压缩失效"方向：该请求的 messages 只有 1.48 MB，压缩标记在迁移前后一一保留（compaction/start 11、summary 11、end 11、prune 15），contextPressure.surfaceTokens 279,257 / contextWindow 1,000,000。

Expected behavior

迁移后应能继续在该会话中对话：要么水位被重新锚定（不重发整份日志），要么该附加项按字节/token 上限截断，使请求体不可能超过 provider 限制。至少不应表现为无法重试的永久失败。

Environment

• dsh 0.1.7-alpha.2；同一会话在 0.1.7-rc.1 上同样复现（0.1.5-rc.3 不含 V4 格式，故不受影响）
• Windows 10 x64，Node 24.15.0，pnpm 11.7.0
• provider deepseek-official（默认 baseURL https://api.deepseek.com/anthropic），model deepseek-flash
• 会话：29,290 事件，multi-frame zstd 日志解压后 84.9 MB

Root cause

packages/session/session-log-deepseek/src/index.ts

• acceptedThrough() 会跳过 session-log-deepseek/delivery-accepted 中 data.sessionFormatVersion !== session.header.version 的事件（约第 136 行）。
• prepare() 取 afterSeq = acceptedThrough(session)，并以 session.snapshotEvents(afterSeq + 1) 组成后缀；afterSeq === -1 即"从头开始发"。

格式迁移后 session.header.version 为 4，而所有历史确认事件都记录 3 → 全部被跳过 → afterSeq 回落 -1 → 附带整份日志。新水位只在 accept()（请求成功后的回调）写入，而请求先 413，永不写入，形成自锁。

按代际限定水位本身是刻意设计（"Highest confirmed sequence for this exact Session format generation"），但迁移路径缺少"重发不可交付"时的重新锚定，而请求体上限（provider 侧）与设计假设的"重发总是可交付"相冲突。

Suggested directions

• 给附加的后缀加字节/token 上限（超限时截断或拒绝），使请求体不可能超过 provider 限制；
• 或在迁移/恢复时重新锚定水位（例如以任意代际的最新接受事件作为后缀下界，或在会话恢复时补写一条接受记录）；
• 至少让失败可见：当前 413 以原始状态码呈现，用户无从判断成因与出路。

Workaround

在 profile patch 中关闭该附加项即可立即恢复（已验证请求体 96.5 MB → 1.53 MB，同会话正常作答）：

- id: session-log-deepseek
  config:
    enabled: false

代价是模型失去按需读取原始会话日志的能力；新会话（日志较小）即使保持开启也只在首次请求付出一次大上传。

[argszero]

Confirmed at HEAD, and the mechanism is exactly the one your measurements point at. Three lines do it:

• packages/session/session-log-deepseek/src/index.ts:136 — if (acceptedFormatVersion !== session.header.version) continue. The acceptance watermark is scoped to the Session format generation on purpose (a payload written under the old format describes the old format), so a V3→V4 migration makes every existing delivery-accepted event invisible. acceptedThrough() returns -1, afterSeq falls back to -1, and prepare builds events from snapshotEvents(afterSeq + 1) — the whole log, every request.
• :118-150 — nothing in the migration path re-anchors that watermark. There is a "replay is undeliverable" state with no representation: the fold has no way to say "this backlog will never fit, start from here".
• :185 — the fix the code does have is gated on the request succeeding: accept appends the new-generation watermark and it is only called after a 2xx. A request that is too large never reaches it.

So the two halves lock each other: the only thing that could move the watermark is the callback that a 413 prevents from running. Hence your observation that it is permanent, ping included, and that disabling the field is the only thing that answers 200. The sizes are consistent with the wall you measured (96.5 MB body vs ~48 MB) — this is a size problem, not the compaction family: your context is fine, the top-level field is not model input at all.

Immediate unblock (no code change): mount @deepseek-ai/dsh-session-log-deepseek with enabled: false in the profile's cordis.patch.yml (config.enabled !== true ⇒ apply returns before registering the field, index.ts:160). You lose server-side raw-log retrieval for that profile; the session is usable again immediately. That is what your 1.53 MB → 200 measurement was.

If you want to keep the field: the registry merge happens in request-extensions.ts:32 (JSON.stringify({...body, ...extensions.fields})) and is reached through ctx.get('deepseekLlmApiExtensions') on every request (llm-deepseek/src/index.ts:103), so the field can be bounded from a plugin without touching core. I published one:

• npm: https://www.npmjs.com/package/@argszero/cordis-plugin-session-log-budget
• repo: https://github.com/argszero/cordis-plugin-session-log-budget

npm install @argszero/cordis-plugin-session-log-budget

# cordis.patch.yml of the profile
- insert:
    - id: session-log-budget
      name: '@argszero/cordis-plugin-session-log-budget'
      config:
        mode: enforce        # or: report, which measures and logs and changes nothing
        maxFieldBytes: 8000000

What it does: it wraps the registry's prepare and, when the prepared field is over the budget, sends the longest contiguous prefix of the backlog (afterSeq + 1 … throughSeq stays a true sentence, which a tail window could not be), suppresses the owner's accept — whose watermark would otherwise claim the whole backlog — and appends its own session-log-deepseek/delivery-accepted record for exactly the prefix it sent, in the owner's own event shape (the suite feeds its records to that package's own invariant, not a re-implementation). The next request starts after the prefix, so the backlog drains a budget-sized piece per request until it is gone, and then the owner takes the healthy path again on its own.

Boundaries, stated rather than left to be discovered:

• It cannot save the first request's build cost: the owner has already built the 90 MB value by the time the wrapper sees it. It stops the field being sent, and removes the per-request cost of every later request.
• While a backlog drains the endpoint holds the oldest part of it first — the price of a prefix.
• A shortened request replaces the registry's joint acceptance transaction, so a sibling field registered by another plugin would not get its commit on that request. dsh_session_log is the product's only field today.
• An envelope larger than the entire budget cannot be delivered at all; the field is left out and the host log names it.

The real fix belongs in core, and it is small: the owner should re-anchor when replay is undeliverable (write a current-generation acceptance record covering what is known to be held, e.g. from the last pre-migration watermark, instead of only ever moving forward after a 2xx). The plugin is a seam fix that works without that change — not a substitute for it.

Tested against 0.1.3-alpha.2 / 0.1.5-alpha.1 / 0.1.7-alpha.2 / 0.1.7-rc.1, each with a clean install and the full suite (56 tests) green; 11 of 12 defect-injection arms caught, 1 recorded as equivalent. Happy to adjust the default budget or the record shape if you want it to match something else.

[txxt114514]

Same field, same lock — but a second way to reach afterSeq = -1: the watermark was never established

We hit this independently on 0.1.7-alpha.2 and ended up at the same three lines. One thing your report and @argszero's confirmation leave open is which way acceptedThrough() arrives at -1. In our session it is not the migration:

	your session	ours
why afterSeq = -1	watermark invalidated (V3-generation events skipped)	no watermark ever existed
evidence	accepted events carry version 3	all 14 accepted events carry sessionFormatVersion: 4 — the same as the header

Measured on the session we recovered (all 122 frames decoded, 206,405,771 B, 40,833 events):

session createdAt             : 2026-09-12 05:01:37Z    header version: 4
delivery-accepted total       : 14    (every one sessionFormatVersion: 4)
earliest accepted             : seq 40717 @ 2026-09-24 05:41:49Z
accepted events before that   : 0
events before the first accept: 40,717 of 40,832   (99.7%)
session created -> first OK   : 12.0 days

The session lived twelve days and 40,717 events with no accepted watermark at all, because the add-on was not enabled for the first part of that life: enabled defaults to false in 0.1.5-rc.3 and to true in 0.1.7-alpha.2 (the two READMEs are worded in opposite directions). Once it became default-on the field started being injected with no prior watermark to anchor to, so acceptedThrough() returned -1 on the very first injection.

That changes where the fix has to go. In our case nothing was invalidated — there was nothing to invalidate. So "do not skip other-generation watermarks" does not cover it, while @argszero's :118-150 point does: "this backlog will never fit" is a state the fold cannot represent, and afterSeq === -1 reaches it for any reason at all. The loop is also self-seeding — accept() can only write the first watermark after a request succeeds, so a session whose first injected payload is already oversized can never reach the state that would fix it.

What we measured, in case it is useful alongside your numbers: the rejected body was 206,429,335 B, of which dsh_session_log was 205,872,373 B and the real conversation surface only 579,474 B. A second sample with 863 messages instead of 208 differed by 1.3 MB — the ~206 MB was a constant riding every request, independent of message count.

Two things we took from your report specifically:

• Your 32 → 48 MB probe is the number we could not obtain. We had bounded the ceiling only to (1.45 MB, 206 MB]. With a real limit that high, a byte guard can sit far above a legitimate token surface; we are moving our local guard from 8 MiB up to ~24 MB on the strength of your measurement. The 413-vs-422 probe (neither consuming tokens) is a neat instrument.
• The repair we would argue for is a byte bound on the contributed suffix itself, plus re-anchoring — not per-cause fixes, because the causes are open-ended: migration invalidation is one, first-time enablement is another.

We also confirmed your workaround on our session. With the field dropped at the adapter, the session's first ever delivery-accepted was written at 05:41:49 and the field fell from 205.87 MB to 93,304 B on the next request; the surface token count went 380,109 → 266,393 and every turn since has completed.

Our byte-level breakdown, and the local gate + degradation-ladder implementation with three rounds of self-review, are in #7699.

[argszero]

Your mechanism holds, and it is a second row in the same table rather than a second bug — worth stating precisely, because it changes what the fix has to cover.

Both triggers converge on afterSeq = -1. acceptedThrough() starts at -1 and its own docstring names that state: "greatest accepted sequence, or -1 before any accepted request". It only counts session-log-deepseek/delivery-accepted events whose sessionFormatVersion equals the header's, so there are exactly two ways to stay at -1: an existing watermark that the format generation skips (the migration route), or no watermark ever written. In apply(), prepare then builds suffix from snapshotEvents(afterSeq + 1) — with -1 that is snapshotEvents(0), the whole log.

Your data pins which route yours is, and it is not ambiguous: 14 accepts, every one carrying sessionFormatVersion: 4 — the same generation as the header — so the version-scoped continue never fired for you. Earliest accepted at seq 40717 of 40832, session created twelve days earlier: the field was simply not being injected for the first 12 days and 40,717 events, because apply() returns early on config.enabled !== true, so no delivery-accepted was ever appended while it was off. Enabling it later starts from -1 with a 40,717-event backlog. Same lock, reached from the other side.

One refinement to your version table. The default flip is earlier than 0.1.7-alpha.2: first shipped in dsh-v0.1.6-alpha.1, from commit 31ec6bc7e3 ("fix(session): keep upload defaults independent of test runners", 2026-09-14), which is what git tag --contains reports. That is also the whole explanation for the two READMEs reading in opposite directions — the wording changed with the default, one release earlier than the version you compared against.

The useful consequence: which route reached -1 does not change the remedy, and there is a shipped plugin that is invariant to it — @argszero/cordis-plugin-session-log-budget@0.1.0 (source: https://github.com/argszero/cordis-plugin-session-log-budget). It wraps the request-extension seam and contributes the longest contiguous prefix of the backlog that fits the budget, then writes its own delivery-accepted for exactly what it sent — so the watermark advances on the first request that fits instead of waiting for a 2xx that a too-large body prevents. Your case is the one that design serves most directly: with no prior watermark to disagree with, the first accepted request is the whole un-locking event, and the rest of the backlog drains over subsequent requests rather than never.

Its sibling @argszero/cordis-plugin-request-body-accounting@0.1.0 is the diagnostic half: it reports the serialized bytes of the base body and of every extension field per request, so "which field ate the request" is a number rather than an inference. On the session in #7699 that measured 205,872,373 of 206,451,866 bytes in dsh_session_log alone — 99.7%.

Honest boundary on both: they bound and name, they do not fix the fold. The core fix is re-anchoring the watermark — the state "this backlog is undeliverable, start from here" has no representation today, which is why the only thing that could move -1 is the callback a 413 prevents from running.

[donyue7]

Independent data point on the open question @txxt114514 raised — which path reaches afterSeq = -1: ours is the "watermark was never established" path, and here is the version-level evidence for it.

• @deepseek-ai/dsh-session-log-deepseek ships enabled: false in 0.1.5-rc.2 ("the default configuration registers no request field and appends no acceptance watermark") and enabled: true in 0.1.7-rc.1. A machine diff of the two releases' bundle trees shows exactly one line changing for this plugin: enabled : false -> true.
• Affected session: 32,809 events (v4 log 22.2 MB compressed). Its pre-upgrade log (session.v3.jsonl.zstd, 32,632 rows) contains 0 delivery-accepted events — the field had never been enabled for it, so no migration was needed to arrive at an empty watermark. The same session completed 2300 official-DeepSeek requests on 0.1.5-rc.2 (last success 2026-09-24 10:54); after upgrading to 0.1.7-rc.1 every official route returned 413 (20 occurrences, 19:48 → 20:12).
• Control: a session created under 0.1.7-rc.1 carries 160 delivery-accepted events (latest throughSeq: 1067) and is healthy — so the mechanism is the empty watermark, not the machine or the provider route.
• Other sessions in the same home with 32,130 / 23,071 / 21,799 / 11,700 events all have 0 acceptances as well; each is one official-DeepSeek turn away from the same deadlock.
• The 413 is not a context-length problem: the request's live (unshadowed) messages are 13 messages / 0.08 MB.

Workaround verified end-to-end (home patch, applies to every profile):

- id: session-log-deepseek
  config:
    enabled: false

After a restart no new delivery-accepted events are written at all, and the stuck session resumed on deepseek-account/deepseek-flash, completing a continuous turn (113 assistant/message, 123 tool calls) with 0 × 413. Trade-off: the official API then receives no session-log suffix (and /feedback delivery stops).

Generalised guardrails for this class (bounded first upload / auxiliary-field isolation / upgrade-path checks): #7737.

[temotee2103]

补充一下我们把同一根因的新证据整理成了一篇补充帖：👉 #7753

那里补了 4 条本贴尚未提到的事实：

1. 0.1.7-rc.1 把 @deepseek-ai/dsh-session-log-deepseek 的 enabled 默认值从 false 翻成了 true（本机 lib/index.js:16 实测）—— 从未主动开启过它的用户，升级后也会中招，这解释了近期为什么突然大面积出现；
2. 现场为什么表现为 TRANSPORT 超时而不是干净的 413：400/413 → INVALID_REQUEST，而重试白名单不含 INVALID_REQUEST；同时 48 MB 请求体上传要约 22.7 秒，逼近空闲看门狗，最终由兜底分支（L1879）以 TRANSPORT 暴露 —— 所以满屏的「DeepSeek Messages transport failed」很可能就是本问题的表象；
3. workaround 建议打在 home 层（$DSH_HOME/cordis.patch.yml）才能覆盖 tui / headless，只改 profiles/web/cordis.patch.yml 盖不住；
4. 小会话（132 / 58 事件，字段≈0 MB）同样报 TRANSPORT —— 提示可能还存在第二个独立原因（可与 @txxt114514 的"水位从未建立"路径对照）。

另外那篇帖子里附了一份 非程序员也能照做的 3 步修复步骤（含一键 PowerShell 脚本与回滚方式），方便普通用户先自救。

核心修复仍然期待官方：迁移/恢复时重新锚定水位 + 给该字段加字节/token 上限 + 让 413 直接可见（与 @argszero 的结论一致）。

[Darkhe55]

Independent data point on the "watermark was never established" path (not the migration path), on
0.1.7-rc.1 / Windows / deepseek-official + deepseek-flash, endpoint https://api.deepseek.com/anthropic.

Symptom matched the report exactly: after upgrading, the first message in an old long session
(the literal text "继续", two characters) failed instantly and deterministically:

{"message":"DeepSeek Messages request failed (413)","code":"INVALID_REQUEST","status":413}

and it repeated on every subsequent turn with no llm/retry event in between (INVALID_REQUEST is not retryable).

Local evidence (all frames of the multi-frame zstd log decoded, delivery-accepted counted per session):

	events	accepted watermark	decompressed log
stuck session (v4)	30,744	0	89.9 MB
same session (v3 generation)	30,711	0	89.9 MB
a session created after the upgrade	620	97 (throughSeq 615)	2.6 MB

So afterSeq = -1 and every request carried the whole log (89.9 MB) — well past the ~8–48 MB
ceiling, and consistent with "any content fails, size of the message is irrelevant".

Two things I could add to the thread:

1. The installed dsh-session-log-deepseek@0.1.7-rc.1 has Config = z.object({ enabled: z.boolean().default(true) })
   — enabled only, no maxBytes, so on that version there is no way to send a bounded suffix.
2. The blast radius is not just the one session: of 29 session generations in this home, 16 have zero
   accepted watermarks and >500 events (2.0–89.9 MB). They are all one official-DeepSeek turn away
   from the same deadlock, even though the plugin was never enabled deliberately.

Confirming the rc.2 fix path: next = 0.1.7-rc.2 on npm, and dsh-v0.1.7-rc.2's source carries
maxBytes: z.number().step(1).min(1).default(8 * 1024 * 1024) with the "longest pending prefix that fits"
behaviour from #5168 — so upgrading should both stop the new occurrences and let the stuck session drain.

Thanks for the source-level confirmations — they made this trivial to verify locally.

[yamingmou]

The watermark is not gone; it is filtered — and that changes what a re-anchor has to carry.

Versions: @deepseek-ai/dsh-session-format-v3-to-v4@0.1.7-rc.2, @deepseek-ai/dsh-session-log-deepseek@0.1.7-rc.2, read from the published tarballs. I did not run a migration; what follows is from reading those two artifacts.

Where the invalidation actually happens

After a V3→V4 migration the old delivery-accepted records are still in the log, with their fields unchanged. The type is in the migration's known set (format-v3-to-v4:1267), and the only delivery-specific code on the path is two checks (:1473–:1476): a marker claiming sessionFormatVersion === 4 is refused, and a marker naming another Session is recorded as foreign. Nothing rewrites the payload — migrateV3EventContent (:1182) only touches compaction/summary, tool/ptc-dispatch, team/message/queued, request/header, assistant.message and assistant.attempt.

So the invalidation is not a deletion. It is one equality on the read side:

const acceptedFormatVersion = event.data.sessionFormatVersion ?? 0;   // session-log-deepseek:111
if (acceptedFormatVersion !== session.header.version) continue;       // :113

The records carry their generation, the reader compares it to the header's, and every pre-migration watermark leaves the accepted set. "The watermark is unusable" and "the watermark is absent" are different states — and this is the first of them, which is why it is the one a re-anchor could act on.

What a re-anchor needs that does not exist yet

Taking the last accepted sequence from a pre-migration marker looks like reading a number out of the log. The migration does something adjacent that shows why it is not.

That stage reassigns sequence numbers: nextSeq = 0 (:1441), const targetSeq = this.nextSeq++ (:1464), and each mapping is pushed as it goes (:1479, :1488), so mapping[sourceSeq] = targetSeq is the coordinate change between the two generations. It also emits events of its own construction on the same counter (:1457, :1543), so the change is not guaranteed to be the identity.

And it knows records may hold sequence references. remapV3References (:1322) exists for exactly that, with a switch over six types — command/done, compaction/summary, compaction/prune, session/title, session/title-llm-request, image/offload — a short circuit when the mapping is the identity (:1323), and a throw when a reference names something at or after the current source sequence (:1327).

session-log-deepseek/delivery-accepted is not one of those six, and throughSeq is a sequence reference in the same sense. So on the far side of a migration that marker holds a number in the old coordinate space, with nothing establishing what it names now. Two things keep that from being visible: the reader skips the marker entirely (:113), and the migration only reads it (:1473). A coordinate that is never converted and never used is quiet in both directions.

That is the part a re-anchor has to carry. Adopting throughSeq from a pre-migration marker as the new lower bound assumes the two generations share a coordinate system, and nothing in these two packages establishes that — the one table that could has six entries. The number is available; the meaning is what is missing.

A form that might recur

For a migration, every field that survives across generations and contains a sequence number is in one of two states: it is in the remap table, or it is not. Records of the first kind are safe because a table entry was written for them. Records of the second kind are quiet while nothing reads them, and misplaced the moment something does — and the change that starts reading them is exactly the change that would be blamed for being wrong.

A cheap check, if it is useful

The mapping is built in the open — one push per source event — so the two coordinate spaces can be compared for a single Session without any theory: dump the pairs and ask how many have sourceSeq !== targetSeq. Any answer above zero is a Session where a pre-migration throughSeq no longer names the event it named.

Version surface

On the published 0.1.7-rc.2, maxBytes is present (session-log-deepseek:19, default 8 * 1024 * 1024) and the equality at :113 is unchanged. So the cap and the invalidation are separate halves, and only one of them moved.

Authorship note: code locations were read by me against the published tarballs of the versions named above; drafting assisted by AI; verification and publication by me. I have no engineering background — if any technical claim reads wrong, please call it out; I will re-verify against the toolchain and correct.

Reported by the OfferKuai Team — Founder: Zhaofeng (Yaming). Website: https://www.offerkuai.com/ | Contact: contact@offerkuai.com

---

中文版

接受标记不是没了，它是被过滤掉了 —— 而这一点改变了"重新锚定"必须携带什么。

版本：dsh-session-format-v3-to-v4@0.1.7-rc.2 与 dsh-session-log-deepseek@0.1.7-rc.2，读自已发布产物。我没有跑迁移，下面全部来自这两份产物的实读。

"作废"实际发生在哪

V3→V4 迁移之后，旧的 delivery-accepted 记录还在日志里，字段一字未改。该类型在迁移器的已知集合内（format-v3-to-v4:1267），而这条路上与投递有关的代码只有两项检查（:1473–:1476）：声明自己是 sessionFormatVersion === 4 的标记会被拒；指名别的 Session 的标记被记成外来投递。没有任何东西改写载荷 —— migrateV3EventContent（:1182）只碰 compaction/summary、tool/ptc-dispatch、team/message/queued、request/header、assistant.message、assistant.attempt。

所以这次作废不是删除，而是读侧的一个等式：

const acceptedFormatVersion = event.data.sessionFormatVersion ?? 0;   // session-log-deepseek:111
if (acceptedFormatVersion !== session.header.version) continue;       // :113

记录带着自己的代际，读者把它和表头的代际比一下，于是一切迁移前的接受标记离开那个已接受集合。"接受标记不可用"与"接受标记不存在"是两种状态 —— 而这里是第一种，这也正是"重新锚定"能作用的那一种。

"重新锚定"需要一个现在还不存在的东西

从迁移前的标记里取出"最后一个被接受的序号"，看上去只是从日志里读一个数字。而迁移做的一件相邻的事，正好说明为什么不是。

那个阶段会重新分配序号：nextSeq = 0（:1441）、const targetSeq = this.nextSeq++（:1464），每处理一条就压入一次（:1479、:1488），于是 mapping[源序号] = 目标序号 就是两代之间的坐标变换。而且它在同一个计数器上 emit 自己构造的事件（:1457、:1543）⇒ 这个变换不保证是恒等。

它也知道记录里可能带有序号引用：remapV3References（:1322）正是为此存在，带一个覆盖六个类型的 switch —— command/done、compaction/summary、compaction/prune、session/title、session/title-llm-request、image/offload —— 并在映射恒等时短路（:1323）、引用指向"当前源序号或更晚"时抛错（:1327）。

session-log-deepseek/delivery-accepted 不在这六个里面，而 throughSeq 在同一个意义上是一个序号引用。于是迁移之后，那条标记里留着一个旧坐标空间的号码，而没有任何东西确立它现在指向什么。两件事让它不显形：读取侧整条跳过它（:113），迁移侧只读它（:1473）。一个既不被转换、也不被使用的坐标，在两个方向上都安静。

这正是"重新锚定"必须携带的部分：把迁移前标记里的 throughSeq 直接当作新下界，等于假定两代共用同一套坐标，而这两个包都没有确立这件事 —— 唯一能确立它的那张表只有六个条目。数字是有的，缺的是它的含义。

一种可能会重复出现的形态

对一次迁移而言，每个"跨代际存活且含序号"的字段只有两种状态：进了变换表，或没进。前一类是安全的，因为有人为它写过表项；后一类在无人读取时安静，在有人读取的那一刻错位 —— 而那个开始读取它的改动，恰好就是出问题后会被归咎的那个改动。

一个便宜的核对（若有帮助）

那张映射表是当众建起来的 —— 每个源事件一次 push —— 所以两套坐标不需要任何理论就能对同一个会话比出来：把成对的号码 dump 出来，问有多少条满足 源序号 !== 目标序号。任何大于零的答案，都是一个"迁移前的 throughSeq 已不再指向它当初指的那个事件"的会话。

版本面

在已发布的 0.1.7-rc.2 上，maxBytes 在（session-log-deepseek:19，默认 8 * 1024 * 1024），而 :113 那个等式没有变。所以上限与作废是两半，只有其中一半动了。

声明：上列代码位点由我本人对照上述版本的已发布产物重新通读；文稿撰写由 AI 辅助；核验与发布由我本人负责。我没有工程背景 —— 若任何技术表述有误，请直接指出，我会对照工具链重新核实并更正。我们是插件作者、不是维护者，本文不陈述任何官方政策。

本报告由 OfferKuai（Offer快）团队提交 —— 创始人：Zhaofeng（Yaming）。官网：https://www.offerkuai.com/ | 联系：contact@offerkuai.com