Feature request: SessionFormatError should name the offending row (seq / row type / source plugin)

[IegreSvolrO]

Feature request: SessionFormatError should name the offending row (seq / row type / source plugin)
Context (from closed thread #7800): refusing source.kind === "plugin" rows at write time is intentional and unchanged rc.1 → rc.2 — the producer in our environment was a third-party plugin (dsh-vision-router 2.2.2, fixed by upgrading to 2.2.3). The genuine core-side papercut we hit is the failure mode: the whole batch fails without naming the offending event, the primary turn error is masked, and session-title generation + projection cache fail on the same encoding path — so the producer is not identifiable from the error message.

Suggested change
In assertV4SourceRowAdmission (packages/session/session-format-v3-to-v4/src/message-sources.ts) the whole row is already in scope at the call site — the switch at :32–:40 dispatches on row['type'] — while the source() helper that actually throws (:7–12) only sees a single message. So no new data flow is needed, just pass the row context into the error:

include row.type (and seq where available) in the raised SessionFormatError;
include the source plugin id when the refused source has one.
This turns today's generic "needed producer-owned source" into "row <type, seq> from plugin X was refused" — enough to locate the producer immediately.

Workaround warning for current users (keep as its own paragraph)
Until producers are patched, the interim fix is a reader-side tolerance: rewrite kind:"plugin" rows into a producer-owned shape inside assertV4SourceRowAdmission instead of throwing. It lives in node_modules, so it must be re-applied after every app update. And rows already persisted in session files keep failing on every encode — so disabling the offending plugin alone does not recover existing sessions; only this tolerance (or cleaning the rows) fixes them, while upgrading the producer prevents new rows.

Optional alternative
Admit kind:"plugin" at encode time as a legacy alias and rewrite it to a producer-owned kind — saves every affected plugin user the same papercut.

[ch-Yuan-cn]

+1 — same papercut here, plus one worked example of the producer side being fixed, in case it strengthens the case for naming the row.

Affected producer: @dsh-external/dsh-graded-mode (the graded/ component of yjh051108/dsh-routing-suite) — four injection sites (userMsg() and three steer calls) still emitting { kind: 'plugin', plugin: 'dsh-graded-mode' }.

Production signature: the tool result is already persisted, then the next step throws; the session log ends at step/end with no error event at all. The only on-disk evidence was the producer's own state file, whose mtime matched the last logged event to the second.

Producer fix in flight: yjh051108/dsh-routing-suite#168 — kind → plugin:dsh-graded-mode (the plugin:${plugin} fallback from session-format-v3-to-v4/src/sources.ts), with a 4-case regression test that is red 3/4 before the patch and green after. Feel free to reuse it as a template; it also pins the second-order effect below.

Second-order effect worth naming in any fix: on v4 kind === 'plugin' is never true, so a producer's own "skip my injected messages" filter silently stops filtering — that is yjh051108/dsh-routing-suite#143 for router-core, where an injected guide can be classified as the task text. Including the source plugin id in the error would surface both at once.