[Bug] Archive can miss child Tabs before metadata cache hydration

[wibus-wee]

Affected area

Session / workspace / local sync

Installation method

Built from source

Lody version or commit

b4d5443

Operating system

macOS 26 arm64; the affected Desktop state flow is platform-independent

Agent or runtime

Desktop local runtime

What happened?

On a cold start, Session Detail becomes interactive as soon as the requested root Session is present in the bootstrap metadata cache. The full workspace metadata scan can still be incomplete at that point. If a user immediately archives the root Session, archive target selection reads the partial sessionMetaCacheAtom and can miss a child Tab whose parentSessionId points to that root.

The result is inconsistent archive state: the root is archived while its lifecycle-owned child Tab remains active.

What did you expect?

Archiving a root Session should not start until the metadata needed to identify all direct child Tabs is hydrated, or archive target selection should read from a complete source. The root and every direct parentSessionId child must transition together.

How can we reproduce it?

1. Create a root Session A and a child Tab T with T.parentSessionId = A.
2. Cold-start Desktop and arrange for bootstrap metadata to expose A before the full workspace metadata scan exposes T.
3. Open Session Detail for A; it resolves because A is already in the active Session cache even though docMetaCacheReadyAtom is false.
4. Immediately choose Archive.
5. Observe that archive target selection sees only A, so A becomes archived while T remains active.

How often does it happen?

Sometimes; it depends on user timing during cold-start metadata hydration.

Relevant log output

No log output is required. The race follows from Session Detail allowing actions before docMetaCacheReadyAtom and archive target selection reading sessionMetaCacheAtom.

Additional context

Discovered while narrowing #569 to the archive-only acceptance criteria from #531. This is pre-existing rather than introduced by #569, but it needs an explicit readiness or complete-query contract and regression coverage.

Before submitting

• I searched the existing issues and did not find a duplicate.
• This report concerns an open-source component in this repository, not a hosted service, Web or mobile app, account, or billing issue.
• This is not a security vulnerability; security reports follow the repository's security policy.
• I removed credentials, private source, conversations, prompts, personal data, and other sensitive information.

[Dante-dan]

I can take this as a focused archive-readiness fix.

The current report gives a concrete race to test: Session Detail can expose the archive action after the root Session is present but before docMetaCacheReadyAtom guarantees that child Tab metadata is complete. I’ll first turn that ordering into a deterministic regression around the archive target selector, then trace whether the smallest safe correction is to gate the action on metadata readiness or to make target selection query a complete source.

I’ll keep the behavioral contract narrow: archiving a root and its direct parentSessionId children must be atomic from the user’s perspective, while already-hydrated archive behavior and unrelated session actions remain unchanged. Before submitting, I’ll run the targeted tests plus the repository’s relevant type, format, docs, and PR-body checks, and I’ll recheck for overlapping work. Any PR will start as a draft and include the required public Context handoff.

[wibus-wee]

@Dante-dan Hi, we already have a fix on the way, this issue stems from several other problems. Thanks for your contribution. :)