Maybe a bug in dsh rc-7

[Mohei-Muun]

AI as reference:

draw/generated session events make sessions unloadable after restart

Environment: dsh 0.1.0-rc.7 (DSH Desktop v2.0.1, Windows) · dsh-draw 0.1.0

Summary

Every image generation appends a draw/generated session event via
session.append('draw/generated', event) (lib/types/session-events.js), but the
event is written without the ignorable: true envelope marker. The harness
session loader (@deepseek-ai/dsh-session's hardcoded KNOWN_SESSION_EVENT_TYPES +
@deepseek-ai/dsh-session-persistence's assertEventsSupported) refuses to load any
log containing an event type outside its built-in 44-type set unless the event is
marked ignorable. Result: any session where the user generated an image fails to
reopen after a harness restart:

SessionFormatUnsupportedError: session "..." contains event type "draw/generated" (seq 73527)
unknown to this harness and not marked ignorable; refusing to interpret the log —
it was likely written by a newer harness

(The log file itself is intact — the loader simply refuses it. "likely written by a
newer harness" is the loader's generic guess, not the actual cause.)

Root cause

lib/types/session-events.js documents the event as "log-only (ignorable)", but the
actual call never sets the flag. The two-argument form was chosen for rc.6 peer
compatibility — however the rc.7 session.append() API does not expose an envelope
option to set ignorable, and the harness currently has no registration surface for
downstream plugin event types (the comment in @deepseek-ai/dsh-session says such a
surface is "deferred until such a consumer exists" — this plugin is exactly that consumer).

Impact

• Session history unavailable after restart; quota accounting in lib/types/quota.js
  (which scans drawGeneratedEvents) also cannot run for these sessions.
• Any future session using image generation will hit the same issue.

Suggested fixes (pick one)

1. Stop emitting the custom event; derive quota/audit from existing standard events
   (tool/call + tool/result) — no harness change needed.
2. Mark the event ignorable: true once the harness exposes a way to set it from
   session.append(), or once a plugin event-type registration surface exists.
3. Coordinate with harness maintainers to add the deferred plugin event-type
   registration surface (dsh-draw is the first real consumer).

Workaround for affected users (meanwhile)

Patch the persisted log to add "ignorable": true to the draw/generated events
(each write batch is an independently zstd-compressed frame; the loader then skips
those events and the rest of the history loads).

[PerryLink]

Confirmed and fixed on main (961bd35) - thank you for the precise report.

The fix (adaptive gate + in-memory fallback ledger): draw/generated appends now go through a mount-time gate (src/event-gate.ts): the event is logged only when the host knows the type or a probe on a detached SessionStore proves Session.append honors the ignorable envelope. On rc.6/rc.7 hosts the probe reads false (their append silently drops the options bag), so nothing unknown lands in the log and sessions reopen cleanly.

Quota keeps working on gated hosts: commits degrade to an in-memory fallback ledger (WeakMap-keyed by session) that quotaState folds on top of the logged events - exact for the live session, reset on restart, and back to durable log-folded accounting once the host gains a plugin event surface. This is the same gate pattern dsh-checkpoint-rewind shipped for its checkpoint/* events, so the family now behaves uniformly on the whitelist builds.

On your suggested fixes: (1) deriving quota from tool/call/tool/result would lose panel-regenerate accounting, which never rides a tool call; (2) is what shipped, with the fallback ledger preserving quota while the envelope is unavailable; (3) remains the right long-term home - dsh-draw is indeed the consumer the deferred registration surface was waiting for, and this issue is good evidence for it.

Regression coverage: tests/event-gate.spec.ts pins the gate decisions, the rc.6 probe reading, and the append-failure degradation. Will ride the next release. Your log-patch workaround ("ignorable": true on the stored frames) is the right repair for already-affected sessions.