[dsh plugin 0.2.1] leafNodes() crashes on first paint under better-sidebar 0.19 — "Cannot read properties of undefined (reading 'kind')"

[DCAMAR]

Symptom

In the DSH (DeepSeek Harness) web client, the Browser Skill sidebar tab throws on first open, every time. Host (dsh-better-sidebar) catches it in its error boundary and shows a "Retry" button; clicking Retry renders fine.

TypeError: Cannot read properties of undefined (reading 'kind')
    at leafNodes  (@wxg-prc-cpg/browser-skill-dsh-plugin/lib/client.cjs)
    at observationTabOpen  (…)
    at evaluate  (…)
    at publish  (…)

Root cause (file + line)

lib/client.cjs — leafNodes() (~L4462) and observationTabOpen() (~L4470):

function* leafNodes(node) {
  if (node.kind === "leaf") {          // <-- throws when node is undefined
    yield node; return;
  }
  for (const child of node.children) yield* leafNodes(child);
}

function observationTabOpen(state) {
  if (state === void 0) return false;                      // only `state` is guarded
  for (const root of [state.splits, state.bottomSplits])   // either can be undefined on the first frames
    for (const leaf of leafNodes(root)) …
}

On the first render the host workbench layout state is not populated yet, so state.splits / state.bottomSplits are undefined → node.kind throws. That is why the first open always fails and the manual retry always succeeds.

Suggested fix (one line)

function* leafNodes(node) {
  if (node === void 0) return;
  if (node.kind === "leaf") { yield node; return; }
  for (const child of node.children ?? []) yield* leafNodes(child);
}

(or skip undefined roots inside observationTabOpen).

Environment

• @wxg-prc-cpg/browser-skill-dsh-plugin@0.2.1 (latest at the time of writing)
• dsh-better-sidebar@0.19.1 (latest)
• DSH 0.1.5-rc.1 · Windows 11 · Node 24

Related observation (same file, likely the same migration)

The tab is still opened with the legacy 0.18-era contract:

service.openTab({ type: OBSERVATION_TAB_TYPE, path: OBSERVATION_TAB_PATH })

Under better-sidebar 0.19 this path appears to be resolved as a file path, producing
cannot resolve target "…/browser-skill-observation": ENOENT on the auto-open path
(manually clicking the tab renders fine). May be worth migrating to the 0.19 tab contract.

Locally we patched leafNodes with an undefined-guard and verified the first-open crash is gone.

[sakkee37]

Root cause confirmed here, and an important release problem:

The fix already exists on main, but it was never published.

• npm latest = 0.2.1 was published 2026-09-09.
• The root guard for this crash landed on main on 2026-09-11 — commit fix(client): guard observationTabOpen against a missing right-column tree (observationTabOpen() now does if (root === undefined) continue).
• So every user on the published version still hits the crash; the fix is only reachable by reading main or patching node_modules by hand.

Why the crash still shows up as dsh-better-sidebar: …

The host (dsh-better-sidebar) catches our render error in its error boundary and prefixes it with its own name, so the message never names this plugin. That misattribution is why the trail in DSH-better-sidebar#620 / #639 points at the host first — the actual stack is ours:

TypeError: Cannot read properties of undefined (reading 'kind')
    at leafNodes           (@wxg-prc-cpg/browser-skill-dsh-plugin/lib/client.cjs)
    at observationTabOpen

It is a first-frame race: state.splits / state.bottomSplits are undefined on the first frames, so the manual "Retry" always renders fine. Reproduced on DSH Desktop 2.0.9 (core 0.1.5-rc.1) with dsh-better-sidebar 0.19.0 and 0.19.1 — i.e. unrelated to the host version.

PR opened

#235 (by @L4XB, opened 2026-09-11 — it closes this issue) hardens the walker itself, so the guard no longer depends on which root is missing:

(an earlier PR of mine, #239, duplicated #235 and is now closed. Earlier #238 was closed after a branch rebase and cannot be reopened.)

function* leafNodes(node: SidebarNodeLike | undefined): Generator<SidebarLeafLike> {
  if (node === undefined) return;
  if (node.kind === "leaf") { yield node; return; }
  for (const child of node.children ?? []) yield* leafNodes(child);
}

It also adds a regression test for a split tree carrying a missing child (the case the existing root-only guard does not cover). This is the same two guards that @DCAMAR verified on real hardware in DSH-better-sidebar#620.

Request: could a patch release (0.2.2) be cut from main? Without it, the fix is invisible to everyone installing from npm — including this reporter.

[DCAMAR]

Confirming from the reporter side — and thanks for hardening the walker in #239.

1. The guards do fix it on real hardware. We patched node_modules locally with exactly the two guards (if (node === void 0) return; + node.children ?? []) and the first-open "Retry" banner stopped appearing — verified on Windows 11 · DSH 0.1.5-rc.1 · dsh-better-sidebar@0.19.1 · browser-skill-dsh-plugin@0.2.1. So the behaviour on main is confirmed here by observation, not only by reading the diff.

2. The release gap bites the reporter too. We are still carrying a local patch that every upgrade overwrites, so npm users (this one included) stay on a known-broken build until a patch release actually lands.

3. → I will verify 0.2.2 on the real machine as soon as it is on npm and report back in this thread, including whether the auto-open path-contract ENOENT is still present.
That second one is host-side (openTab path seeds being resolved as file resources) and is tracked separately in omdsh-dev/DSH-better-sidebar#632 — not a blocker for this issue.

4. On the misattribution: thanks for spelling out the mechanism. The host prefixing our stack with its own name is exactly why our first pass searched the wrong repository. If the plugin could self-identify in that boundary message (one line, e.g. logged before the walk), the next reporter would land on the right repo immediately.

[sakkee37]

Thanks for the hardware confirmation — that closes the loop on the half I could only check locally (macOS arm64): the same two guards, the same outcome, on a completely different stack (Windows 11 · 0.19.1 · 0.2.1).

One clarification so nobody waits on the wrong PR: the open fix is #235 (fix(dsh-plugin): tolerate an unpopulated sidebar layout on first paint, by @L4XB). Its open-source compliance scan is already green; only the maintainer-side workflow approval and review are outstanding. The PR you mentioned, #239, was my duplicate of it and is closed — so #235 is the one to watch for the release that gets all of us off the node_modules patch.

We're carrying the same local patch here, so +1 that the release gap — not the workaround — is the actual blocker for npm users.

On misattribution: agreed, and your "self-identify before the walk" is the plugin-side half. The host-side half is small too — dsh-better-sidebar's shared RenderBoundary renders dsh-better-sidebar: {error} for any subtree it wraps, even though its own componentDidCatch already has the full error.stack in hand. Naming the first non-host frame in that strip would send the next reporter straight to the right repository instead of to the host's issue tracker. I'd like to propose that once #652 (which touches the same error-containment path) has settled, rather than collide with it.

[DCAMAR]

Thanks for the pointer — correcting my side too: I had #239 in my notes as the one to watch, and it is now closed as a duplicate. Following #235 from here.

+1 on your read that the release gap is the real blocker — we are carrying the same local patch (Windows 11 · DSH 0.1.5-rc.1 · dsh-better-sidebar 0.19.1 · browser-skill 0.2.1).

On the host-side half: agreed, and the asymmetry you describe is the interesting part — the boundary already holds the full stack, so naming the first non-host frame in that strip is nearly free. Happy to wait for #652 to settle; when you open that proposal I can add our stack as a second data point if it helps.

[sakkee37]

Status update for anyone landing here: #236 was merged into main on 2026-09-15 (fix(dsh): use native sidebar with floating fallback). It supersedes the guard-based fixes by removing the layout traversal entirely — observationTabOpen() / leafNodes() no longer walk splits / bottomSplits, so this crash class is gone at the source rather than merely defended against. The direct-integration route makes sense given the two-sided maintenance cost.

One thing worth flagging so the fix isn't stranded: the published package is still @wxg-prc-cpg/browser-skill-dsh-plugin@0.2.1 (2026-09-09) — npm dist-tags.latest has not moved and there is no new dsh-plugin release tag — so #236 is not reachable for anyone installing from npm. The local node_modules patch is still the only thing keeping first paint clean here, and per @DCAMAR's note above it is the same on their side.

If a release from main is planned, that is the step that closes this issue for npm users. Happy to verify it on this end (macOS arm64 · DSH Desktop 2.0.9 · core 0.1.5-rc.1 · dsh-better-sidebar 0.19.0) as soon as it is published — and @DCAMAR offered to verify on Windows 11 as well, so you'd get both platforms confirmed in this thread.