v0→v3 migration refuses unknown historical events even when ignorable — legacy logs become unopenable after upgrade (measured impact + asks)

[Ericality]

What we observe on 0.1.5-rc.2

Opening a session written by an older harness (0.1.2-rc.1, i.e. a v0 log) fails with:

Failed to load history: failed to observe session "…":
format v0 contains unknown historical event type "notice/banner" at seq 303;
migration refuses unknown historical events even when ignorable;
source v0 artifact remains unchanged

• The log is not modified (good), but the session is unopenable in 0.1.5 — it still shows in the list.
• Measured impact on one instance (243 sessions): 120 contain our plugin event type; 52 contain an unrelated legacy payload member — permission/preset.data.origin (value "default", written by an earlier harness build, apparently benign); union = 128 sessions (52.7%), including 16 of the 49 sessions touched in the last 24h. Blocks are listed by "last write day", so this is not only ancient history.

Two independent causes, both in the frozen v0 inventory

1. Unknown event type (notice/banner, out-of-repo ⇒ "outside the list by construction").
2. Unknown payload member (permission/preset.data.origin) — rejected as has unexpected member "origin".

Writer-side fix (#1538) does not rescue already-written v0 logs

We verified in a sandbox that patching the frozen v0 inventory makes those logs readable, but the session then cannot be written: appends returned success while nothing landed on disk and no v3 was derived (silent data loss). A clear refusal is strictly safer than that half-fixed state — worth keeping in mind if the v0 edge is ever relaxed.

Asks

1. Land the ignorable writer surface proposed in Out-of-repo plugins cannot mark session events `ignorable` — every log they touch becomes unreadable (extensibility gap + minimal fix) #1538 (accepts { ignorable?: true } for non-surface events). This also removes the "uninstall poisons previously written logs" class and matches how our events are already being read today (they are read while the plugin registers the type in-process).
2. For already-written v0 logs, please provide a supported path, any of:
   • honor ignorable on the v0 edge as well (today it refuses even ignorable: true), or
   • an explicit opt-in migration mode that keeps unknown historical events opaque instead of refusing the whole log, or
   • a documented recovery affordance (e.g. the "skip unknown events and open" action suggested in Session logs become unreadable after a plugin that wrote session events is uninstalled #2228).
3. Document the supported practice for UI-only notifications. Our banners are pure UI cards; the docs describe plugin-declared event types as log-only audit records (never surface events), so persisting them is a semantic mismatch — but we found no documented alternative channel for "show a card in the conversation view". A short doc section would prevent the next plugin from repeating this.

What we can provide

Sanitized repro: two sample logs (one with the unknown event type, one with the extra payload member), the exact error strings, and the minimal patch we used to prove the read/write asymmetry — all on request.

[Robin1987China]

Thank you @Ericality — this is a careful report, and the part that will save other people the most pain is the sandbox result you volunteered at the end. Restating your diagnosis so it is clear what I verified: opening a v0 log written by an older harness fails with format v0 contains unknown historical event type "..." at seq N; migration refuses unknown historical events even when ignorable; you identified two independent causes in the frozen v0 inventory — an unknown event type (out-of-repo, so outside the list by construction) and an unknown payload member (permission/preset.data.origin) — and you warned, from your own experiment, that patching the frozen inventory makes a log readable and then loses writes silently. Your framing that a clear refusal is strictly safer than that half-fixed state is the most valuable claim in the thread, and I have quoted it rather than re-derived it.

Both causes reproduced, with the refusal produced by the official function

I did not re-implement the decision rule. @deepseek-ai/dsh-session-format-v0-to-v1 exports assertReleasedEventPayload(event, version), which the migration itself runs over every event, so I called that and read what it says.

To avoid the trap of hand-built events failing for the wrong reason (a missing required member, a bad semantic type), I started from real logs the validator already accepts and changed exactly one thing. 12 of the 32 v0 logs in my corpus are clean; the fixtures come from those:

fixture	the one change	assertReleasedEventPayload says
v0-unknown-event-type	appends notice/banner with ignorable: true	format v0 contains unknown historical event type "notice/banner" at seq 4; migration refuses unknown historical events even when ignorable
v0-unknown-payload-member	adds origin to a real permission/preset event's data	permission/preset 0 data has unexpected member "origin"
v0-control-clean	nothing	no refusals

So both of your causes reproduce exactly, and your ignorable ask is confirmed at the code level rather than only in the error text: at dsh-session-format-v0-to-v1/lib/index.js:1528-1530,

const ignorableCurrent = !allowLegacySteering && !currentKnown && record["ignorable"] === true

ignorableCurrent is computed only when the call is not on the legacy-steering path. The v0 edge sets allowLegacySteering, so an unknown type with ignorable: true can never be rescued there — which is precisely the asymmetry your ask 2 targets, and it also means the v1 edge already behaves the way you want the v0 edge to.

The second cause is structural too: permission/preset is declared disposition(["preset"]) (:119), so origin is refused by the declared member set, not by anything specific to presets.

One correction, and it is about how many people this hits

I could not reproduce your measured impact, and I want to be explicit about which half that is. Your 128 of 243 sessions (52.7%), including 16 of the last 24 hours, is measured on an instance whose plugins write their own event types. My corpus is a different population and contains neither shape — it has the descriptor-version failure and nothing else — so I built the two fixtures above rather than claiming a rate. The mechanism is population-wide; the incidence is per-plugin, and it scales with how many of your sessions were written by plugins that declare their own event types. That does not weaken your report, but a reader should measure their own logs before concluding they are affected: a log is refused only if it actually contains one of the two shapes.

An independent bug the cross-check exposed in my own tool

I ran the official validator over my whole corpus and compared its verdict with dsh-session-check's. The first comparison reported 26 refusals and 6 disagreements against the tool's 20 — and both numbers were my bug, not the tool's:

1. I ran the v0 validator over 9 logs at later generations. Those legitimately contain post-v0 event types and payload members (system/message, request/context.systemPromptUpdate, assistant/message.stream), and the v0 validator refuses all of them. Not migration refusals at all. Restricted to version === 0: 26 → 20.
2. I keyed the comparison by the log header's id; a header without one produced undefined on one side and was printed as a disagreement. Keyed by path: 6 → 0.

Final state: 41 logs, 32 at format v0, validator refuses 20, the scanner refuses 20, 0 disagreements. Worth reporting because the same population mistake applied to the scanner was worse: findLogs matched only the v0-era session.jsonl.zstd, so 9 of 41 logs were never scanned at all while the version tally still looked complete. Fixed in 0.1.3 — it now accepts session.jsonl.zstd, session.v3.jsonl.zstd, and session.v3.jsonl, and the extra 9 logs produced no new refusal.

What is published

dsh-session-check@0.1.3 adds two gates for exactly your two causes:

• v0-unknown-event-type and v0-unknown-payload-member, reported by a scan of ~/.dsh/sessions.

They are not mirror implementations. They call assertReleasedEventPayload and classify its refusals, because mirroring would mean copying the frozen 51-type inventory into the package, and a stale copy produces false positives — the one failure a diagnostic like this must never have. Consequences I made explicit rather than implicit:

• They run only over format-v0 logs, for the reason in the previous section.
• If the harness is not installed, the scan prints official validator : UNAVAILABLE — <reason> instead of a clean-looking result.
• A subagent/descriptor refusal is attributed to the existing stale-descriptor gate and dropped here, so no session is counted twice. Pinned by a test.
• The scan prints the inventory's shape (51 types, frozen=true, list-matches-dispositions=true) and warns when it is not frozen or its derived list no longer matches its dispositions. That is the practical form of your warning: detect a hand-patched inventory instead of keeping a copy of the names.

Your verify-it-yourself command:

npx -y dsh-session-check scan ~/.dsh/sessions

On your write-back finding

I did not reproduce your sandbox experiment, so it stays quoted as yours. What I did verify is the mechanism that makes it credible, because it is the reason I put the warning in the tool rather than only in a README:

dsh-session/lib/index.js:270 retains an event whose type is not in KNOWN_SESSION_EVENT_TYPES only when it carries ignorable: true; otherwise the generation it was derived into refuses the log. So accepting an unknown type at the v0 edge does not remove the refusal — it relocates it to the write path, where it is silent. That is exactly the "readable, then appends return success while nothing lands" state you measured, and it is a strictly worse place for the failure to live than the loud refusal you have today.

On asks 1 and 3

Both are upstream's, and I have no way to land them (external PRs are not accepted). Two notes that may help whoever does:

• Ask 2's option "honor ignorable on the v0 edge as well" is a one-condition change at :1528 — ignorableCurrent currently excludes the legacy path by construction. But it is not free: with the event then retained in the derived v3, dsh-session/lib/index.js:270 drops it from the read view unless it is ignorable, so the observable result for a non-ignorable unknown type would still be loss. Honoring ignorable is safe precisely because the event says it can be dropped.
• Your ask 3 (a documented channel for UI-only notifications) is the root cause of the whole class: the docs describe plugin-declared event types as log-only audit records, so a plugin wanting a conversation card persists an event it does not really own. The guide now says so.

Also worth knowing

While verifying a separate report I measured that a plugin's ctx.logger.warn reaches neither stdout nor stderr in a stock dsh web run: Cordis's built-in LoggerService installs only an in-memory ring-buffer exporter, and no installed @deepseek-ai/* package registers a console sink. So the fail-soft path that would tell someone their log was refused may itself be going nowhere. Verified on 0.1.5-rc.1 under dsh web only, so treat it as a lead — but if you are relying on a log line to surface this class, check it is visible first.

Not verified

• Your 243-session measurement, and the union figure of 128 (52.7%). Different population, and my corpus has neither shape.
• Your sandbox write-back experiment.
• Whether a supported recovery path exists for already-written v0 logs. That is an upstream design question; the scan only tells you which logs will hit it.

The full evidence, including the two fixtures' construction and the corpus comparison with the first-run bug recorded: docs/verification.md.