Sessions silently leave their Workspace and reappear under "Ungrouped" (membership filter + startup-only cwd index + durable prune)

[leo-sam]

Summary

Sessions that were created inside a specific Workspace intermittently show up under "Ungrouped" in the sidebar instead of their Workspace. Once it happens, the eviction can become permanent, even though the durable workspace record still lists the session.

Environment

• dsh 0.1.7-alpha.2 (source analysis at commit 00102833)
• macOS arm64, desktop app

How "Ungrouped" is decided

ungroupedMemberIds in packages/client/ui-workspace/src/client/rows/WorkspaceBrowser.tsx is simply "every session not contained in any workspace.sessionIds". So "session moved to Ungrouped" ⇔ "some workspace's sessionIds no longer contains the session".

Mechanism (source analysis)

Workspace.sessionIds is a live-filtered projection, not the durable account:

// packages/workspace/workspace/src/entity.ts
get sessionIds(): readonly SessionId[] {
  return this.record.sessionIds.filter(id => this.host.sessionPath(id) === this.record.path)
}

sessionPath(id) reads a sessionPaths index that is built only during WorkspaceRegistry startup (Service.init → replaceHeaderIndex(listStoredHeaders()) + indexLiveSessions() in packages/workspace/workspace/src/index.ts). There is no session/created / resume / persistence-change listener that keeps it current — packages/workspace registers no session/created listener at all.

Consequences:

1. Silent eviction on index mismatch. Any session whose canonical cwd doesn't match the workspace path at index time disappears from the membership projection with no user action involved. Concrete triggers:

   • the project directory was renamed/moved on disk — workspace.path is immutable and "never rewritten afterwards, even when the directory disappears" (packages/workspace/workspace/src/types.ts), so the divergence is permanent;
   • a transient fs.realpath/stat failure on the cwd during Host startup — indexHeader records invalidSessionPaths on any throw (unmounted external volume, iCloud/permission hiccup);
   • a symlink retarget between workspace creation and session creation.

2. Eviction becomes durable and destructive. WorkspaceEntity.mutate() prunes record.sessionIds through the same filter on every accepted workspace mutation (a rename, another session's attach, a reorder…). So a transient indexing miss is permanently written into the workspace record by the next unrelated edit.

3. The Host feed is internally inconsistent. In packages/api/workspace-controller/src/feed.ts, workspaceView() (used for the baseline and for new workspaces) projects the filtered live getter, while changedWorkspaceView() (upserts for existing workspaces) projects the raw record.sessionIds with no filter. Depending on which path published the last frame, the client flips a filtered-out session between "in workspace" and "Ungrouped" — visible flip-flopping.

4. Attach failure at creation parks the session as Ungrouped forever. session.create publishes the session first and attaches second (packages/api/session-controller/src/commands.ts); on attach failure the client deliberately keeps the published session visible as Ungrouped ("Publication precedes attachment", packages/api/session-controller/src/client/sessions/manager.ts). A transient cwd-resolution failure at that moment leaves the session born-Ungrouped, and nothing re-attaches it later.

The only diagnostic that exists today is a startup logger.warn per filtered candidate (reportFilteredCandidates), which is easy to miss.

Reproduction hints

• Create a Workspace with sessions, rename/move the project directory on disk, restart dsh → the Workspace's sessions show under Ungrouped (workspace.path is stale by design).
• Or cause a transient realpath/stat failure on the cwd during Host startup (unmounted external volume, iCloud/permission hiccup) → same result after restart.
• Once one session is evicted, any unrelated workspace edit (rename the workspace, attach another session) prunes it from the durable record, making it permanent.

Suggested fixes

1. Membership projection: rebuild or reconcile the canonical-cwd index at runtime (e.g. on session/created and persistence-listing changes) instead of startup-only.
2. Don't durably prune on the filtered projection: reserve record rewrites for explicit user operations (attach/detach/move), or re-validate against a fresh header read before pruning.
3. Make workspaceView and changedWorkspaceView consistent (both filtered, or both raw with client-side reconciliation).
4. Surface filtered candidates in the UI (or at least a visible warning) — today the eviction is completely silent.

Happy to provide my storage state (~/.dsh/storages/workspace.json) or Host logs if useful.

[argszero]

Your mechanism holds on the current tree — I re-read all four of the places you cite at 00102833's successors, and the chain is unchanged:

• packages/workspace/workspace/src/entity.ts — get sessionIds() filters record.sessionIds through host.sessionPath(id) === record.path, and mutate() re-applies the same filter before it persists. So one transient indexing miss plus any later accepted write on that record is the durable loss you describe.

• packages/workspace/workspace/src/index.ts — the index is built in Service.init (replaceHeaderIndex(await listStoredHeaders()) then indexLiveSessions()), and indexHeader() records invalidSessionPaths on cwd === undefined, on a realpath/stat throw, or on a non-directory — it never keeps the previous good path. A missing entry is indistinguishable from an unplaceable one.

• Same file, reportFilteredCandidates() — one addition to your write-up: a per-id warning does exist, but it runs once, at init, and only for ids the durable record still lists:

  workspace '<id>' filtered session '<id>' from membership: cwd '<x>' does not resolve
  

  The write that actually persists the loss happens later, on an unrelated mutation, and logs nothing. So the only trace of the damage appears before the damage.

Where I would push back on one sentence: "there is no re-attach path" is half true. The write side is already public and already used by other flows:

async attachSession(sessionId)   // packages/workspace/workspace/src/entity.ts

It re-reads the stored header, re-canonicalizes cwd, requires the result to be that workspace's own path, and is a no-op when the record already lists the id. What is missing is not the capability — it is (a) a census that notices the projection and the record disagree, and (b) a caller who asks. Both fit in a plugin, so I published one:

@argszero/cordis-plugin-workspace-membership-doctor@0.1.0

• npm — https://www.npmjs.com/package/@argszero/cordis-plugin-workspace-membership-doctor
• source — https://github.com/argszero/cordis-plugin-workspace-membership-doctor

One insert: entry in the profile patch (the package declares dsh.bundle.patch); no configuration.

It censuses stored headers against the published workspaces using the registry's own realpathNormalize, so its classification cannot disagree with the index that did the filtering, and it separates three lists that the product currently collapses into "Ungrouped":

list	meaning	damage?
candidates	cwd resolves to this workspace's path, and the workspace does not list it	yes — exactly the eviction you describe
cause set	this process cannot place the cwd at all (no cwd / not absolute / not a directory / does not resolve)	not yet: these are the sessions the next write will drop, while they are still members
ungrouped	canonical cwd is no workspace's path	no

plus one tool, workspace_membership: report (writes nothing) → action: "repair" (returns the plan, still writes nothing) → action: "repair", confirm: true (re-attaches the candidates through the registry's own validated attachSession, then re-reads and re-censuses). Nothing runs automatically at startup, on purpose: a deliberate detachSession and a silent prune leave identical records behind, so an unattended repair would undo the first while fixing the second. Every report ends with a coverage block (workspaces read, headers read, cwd resolved, matched, ungrouped), and when the headers cannot be listed at all it says the census could not be taken instead of printing zero candidates.

Verification, in case it is useful to you: 71 assertions over the census, the repair loop, the renderers and the tool path; a 20-arm mutation harness where each arm breaks one decision and the suite must fail — 19 caught, and the 20th is a deliberate semantic no-op that the harness requires to survive, which is what shows the other 19 fail for the reason claimed. The suite was run against both 0.1.7-alpha.2 and 0.2.0-rc.2, and the peer range names only those two lines rather than the span between them.

Two limits that matter for your four triggers:

• The census cannot distinguish "the record still lists it but the index lost it" from "the record already dropped it" — the registry publishes only the filtered projection. It does not need to: attachSession is idempotent for both, so the repair is the same.
• A second process sharing the same DSH_HOME can re-prune what this repairs — the same root cause as [Bug]: Concurrent dsh instances sharing one DSH_HOME wipe each other’s workspace session membership #1485, and also raised in 0.2.0-rc.1 升级后部分会话被静默移出工作区（显示未分组） #8237, where the reporter corrected the V3→V4 attribution to precisely that. There the census keeps reporting the candidate, and the report says that state is worth reporting upstream rather than retrying, but the durable fix is one instance per DSH_HOME, not a plugin.

Your cause #1 (the directory was renamed or moved on disk) is also worth calling out as out of scope on purpose: workspace.path is never rewritten, so a moved directory makes every member a candidate at once, and the plugin reports nothing for them — a session whose canonical cwd no longer matches its workspace is the case the registry is right to prune. That one needs a workspace-path rewrite path, not an attach.