Bug report: Session containing deleted/corrupted plugin cause dsh unable to load the session log

[nekomona]

Problem

The session context contains an error caused by a plugin during development. The plugin is removed before restarting dsh. After the restart, the session containing that plugin tool call raise an error and refused to load the content of this session. This only shows for the given context, possibly related to the given context.

Impact

Unable to debug or fork the session from UI. The session content is only accessible through decompressing session zstd.

Expected outcome

The error due to unknown tool or bad tool context should be isolated to the single tool call. For the given session, the unknown tool should be labeled instead of blocking the whole session load. The user should be able to check the previous part of this session, locate the error message, or fork from this session in UI.

DSH Error info

历史加载失败：stored session "session-16467daa-585f-4fac-a3b0-1d339d5c4926" is corrupt: stored session "session-16467daa-585f-4fac-a3b0-1d339d5c4926" failed validation: Error: session event at seq 2625 message must contain one tool-result block（internal）

Corresponding session content (partial)

{"type":"tool/call","seq":2624,"time":1788265776210,"data":{"turn":1,"step":1,"callId":"call_8cce665fff30f997|8887cca33bb8a283","name":"x_status","arguments":"{\"light\":true}"}}
{"type":"tool/result","seq":2625,"time":1788265779137,"data":{"turn":1,"step":1,"message":{"source":{"kind":"tool","callId":"call_8cce665fff30f997|8887cca33bb8a283"},"content":[{"type":"tool-result","toolCallId":"call_8cce665fff30f997|8887cca33bb8a283","content":"profile: default\ntunnel: running\ndaemon: up\ndaemon_user: x\nload_line: load(\"/tmp/[redacted user info]\")","isError":false}],"role":"user","id":"290f33e5-b325-4206-af1d-eaa6da3b5079"}},"sourceEventSeqs":[2624],"surfaceOp":"append"}
{"type":"step/end","seq":2626,"time":1788265779138,"data":{"turn":1,"step":1}}
{"type":"step/start","seq":2627,"time":1788265779175,"data":{"turn":1,"step":2}}
{"type":"assistant/chunk","seq":2628,"time":1788265779181,"data":{"turn":1,"step":2,"chunk":{"type":"finish","reason":{"kind":"error","failure":{"message":"content.some is not a function","code":"UNKNOWN"}}}}}
{"type":"step/end","seq":2629,"time":1788265779182,"data":{"turn":1,"step":2}}
{"type":"turn/end","seq":2630,"time":1788265779183,"data":{"turn":1,"reason":{"kind":"error","error":{"message":"content.some is not a function","code":"UNKNOWN"}}}}

[Mide69]

Traced this to the exact line, and the "corrupt" call is actually correct, the stored data itself is malformed.

packages/core/session/src/index.ts:339-345 requires the tool-result block's content field to be an array (Array.isArray(block.content)) before it accepts the message. Look at your own pasted event at seq 2625:

"content":"profile: default\ntunnel: running\ndaemon: up\ndaemon_user: x\nload_line: load("/tmp/[redacted user info]")"

That's a bare string, not a ContentBlock[] array. The correct shape would be something like content: [{ type: 'text', text: '...' }]. Since it's a plain string, Array.isArray fails and the validator throws exactly the message you're seeing.

This also explains your second symptom in the same log. content.some is not a function makes sense once you know content is a string: somewhere downstream, code calls .some() on it expecting an array, and strings don't have that method.

x_status isn't a tool name anywhere in this repo (grepped the whole tree, zero hits), so this looks like the removed third-party plugin's own tool implementation returned a malformed tool result, string instead of array, and dsh persisted it as-is with no write-time validation catching the shape mismatch. So the root defect is in that plugin, not core dsh, but I think your actual ask stands regardless of whose fault the bad data was: right now one malformed event permanently blocks the entire session from loading, with no way to inspect or fork anything before it. Isolating a validation failure to the one offending event (label it unknown/corrupt and let the rest of the session render) seems like the right behavior independent of how the bad data got there in the first place.