最新版v0.1.2-rc.1有没有遇到过无法对话的问题

[wyt235]

不论发送什么内容， web网页上都会出现：Cannot read properties of undefined (reading 'find')

[argszero]

Thanks for the report. "Cannot read properties of undefined (reading 'find')" on every send (regardless of content) is a broad signal — the error is in a shared render/apply path, not a specific conversation node. To pin it I'd need the exact call site from the browser console stack trace (the line that does the .find, not just the message).

That said, I traced the client source and there are a few .find() sites on possibly-state-derived arrays that fire on the message path and could be the culprit on a fresh 0.1.2-rc.1 load. If you can grab the stack's top frame, that would disambiguate immediately. The candidates:

1. view-selection.ts:15-16 — resolveActiveView calls tabs.find(...). tabs comes from useConversationViews(value => value) (ConversationSession.tsx:63). conversationViews is initialized to viewTabs() (apply.ts:146) and refreshViews always sets an array, so in the steady state this is safe — but if a view snapshot is ever read before registration, tabs would be undefined and this throws. This is the most likely one for a pre-conversation crash (it runs on the session header for every session).

2. ConversationRoot.tsx:239-240 — sessionWorkspace / pendingWorkspace do workspaces.items.find(...). items is used as an array throughout (navigation.ts:91), so it should be safe, but if the workspace list snapshots as undefined before the first load it throws.

3. ChatView.tsx:443 — railItems.find(...) inside realizePendingJump. railItems is a useMemo, so this is guarded by construction; less likely to be the every-send crash.

The biggest clue is when it happens: does the error appear immediately on page load (before the conversation renders), or only after you send a message? If it's immediate, view-selection.ts is the prime suspect — tabs being undefined when the session header renders. If it's on send, it's likely a message-apply transform.

Could you share the full console stack (the first few frames showing the .find call and the file it's in)? That lets me confirm which of these it is and whether it's a 0.1.2-rc.1 regression vs a pre-existing gap. I'm also happy to dig into whichever one the stack points at.

[wyt235]

After using pnpm dsh web, I accessed 127.0.0.1:3080. The entire page rendered normally, and the previous sessions appeared to have no issues.
However, when I selected a session and sent a message, an error occurred on the page. It immediately displayed "Cannot read properties of undefined (reading 'find')" in the session area, as if it were an AI reply.

I didn't see any relevant error messages in the F12 console. This is the Session log for the new session.

{"type":"permission/preset","seq":0,"time":1788502421830,"data":{"preset":"workspace-write"}}
{"type":"sandbox/mode","seq":1,"time":1788502421830,"data":{"mode":"workspace-write"}}
{"type":"approval/policy","seq":2,"time":1788502421830,"data":{"policy":"ask"}}
{"type":"agent/inbox/spliced","seq":3,"time":1788502428391,"data":{"target":"next-turn","start":0,"inserted":[{"content":[{"type":"text","text":"11"}],"source":{"kind":"user","rpcId":"ec32a7b3-e489-4e48-8da5-de8b4adf76b7","clientTimeZone":"Asia/Shanghai"},"role":"user","id":"02405fae-1722-4e08-9742-a47d5b4cc67f"}]}}
{"type":"turn/start","seq":4,"time":1788502428392,"data":{"turn":1}}
{"type":"agent/inbox/spliced","seq":5,"time":1788502428392,"data":{"target":"next-turn","start":0,"removedCount":1,"inserted":[]}}
{"type":"turn/end","seq":6,"time":1788502428394,"data":{"turn":1,"reason":{"kind":"error","error":{"message":"Cannot read properties of undefined (reading 'find')","code":"UNKNOWN"}}}}

[wzkris]

莫名其妙的说我有个code模式，但是我啥模式都没创建啊，根本无法切换，也无法对话，不知道什么bug

[chinamarkisme]

去设置中，选择agent预设，选择一个模式。然后看好了没有。

[Rjerk]

兼容问题，session 元数据用的 code preset 现在不存在了。我是让 AI 给建个 code preset 就能打开老对话了，映射原先的 ptc preset

我有这俩就可以打开了

~/.dsh/.agent-presets/code/preset.yml
~/.dsh/.agent-presets/code/agent.cordis.yml

因为目标 session 保存的是精确的 preset ID：

json
"agentPreset": "code"


而当前 DSH 已经没有内置 code，只有：

text
standard, ptc, minimal, cordis


恢复时 DSH 会先按 code 查找 preset；查不到就直接失败，还没进入历史消息重放阶段。

所以方案 A 的本质是：

text
让当前系统重新认识一个名为 code 的 preset


具体做法是新建：

text
/Users/rjerk/.dsh/.agent-presets/code/


但这个 code preset 的实际 composition 使用当前合法的：

yaml
mode: ptc


因此：

- 外部 ID 仍叫 code，匹配旧 session 的 header；
- 内部工具呈现模式使用当前版本支持的 ptc；
- 不修改原始压缩 session；
- 不修改 session 的历史事件；
- 不需要把已经开始的 session 强行切换 preset；
- DSH 的 preset discovery 理论上会通过热加载发现它。

这相当于加了一个兼容别名：

text
旧 session: code
当前实现:   ptc


但需要特别说明：

code-review 的修改不是方案 A 必需的，也不能解决目标 session 的问题。目标 session 是 code，不是 code-review。我之前修改 code-review 是误判，属于无关改动；真正与目标 session 相关的只有新建 code 兼容 preset。

[nnshi-s]

可能是旧版本的插件不兼容新版本dsh导致的，我自己是在0.1.1-rc2上装了dsh-routing-suite，更新到0.1.2-rc1之后就出现了这个问题。把这个插件删了就好了。

[CodeMasterYi]

PTC模式旧版本的mode id是code吧？新版本该模式的mode id改成了ptc。