After the 1.4.3 → 1.4.4 update, resume refuses a healthy view written by 1.4.3 (projectionUnavailable, empty cursor) and no events reach the client; a missing view is rebuilt fine (1.4.4) #100

Where is the problem?

Something else / not sure (the host's MSP session view, reached via muse serve)

What happened, and what did you expect instead?

After the launcher auto-updated Muse Code from 1.4.3-R5018.1 to 1.4.4-R5419.1, a long session whose view 1.4.3 had written cleanly can no longer be live-tailed. session/resume returns viewCursor: "" and history: {"mode": "none", "noneReason": "projectionUnavailable"}. turn/start is still accepted (disposition: "started"), and the turn runs and completes in session.jsonl. The client receives no notification for it: no turn/started, no item/*, no turn/completed, and no session/viewHealthChanged. Thirty minutes later the host sends session/closed (reason idle).

The view on disk was not damaged. ~/.local/share/muse/sessions/.msp-view-v1/<session>/HEAD.json still says "status": "healthy", and its source_through.sequence (11047) is exactly the journal's last record at the time 1.4.3 stopped. It was not ahead of the journal, which is the #94 case, and it had not stopped mid-run, which is the #60 case. Nothing in local-tracing records the refusal.

Bisect. I used a scratch copy of the session (HOME and the XDG_* variables pointed at a copy, muse serve --provider echo --disable-shell --disable-write) with the journal truncated to record 11047, the state 1.4.3 left it in:

Once 1.4.4 has appended records to the journal, 1.4.3 refuses the old view as well. So the session stays silent for every client until somebody removes the view directory by hand.

The session had about 12k records and a 3.9 MB view journal (generation 2926, head_view_ordinal 2194). Small sessions resumed under 1.4.4 in the same data root projected fine, so a minimal fixture may not trigger it. The journal holds private repository content, so I can't attach it, but I can share HEAD.json, the snapshot metadata and per-record-type counts.

Expected

• A host that cannot continue a view written by an older build rebuilds it from the journal, as it already does when the view directory is missing, instead of reporting projectionUnavailable.
• If it really cannot serve a live view, turn/start should not be silently accepted, or session/viewHealthChanged should be pushed, so that a client can tell the user. Today a client simply waits.

Workaround: stop every host that has the session loaded, move .msp-view-v1/<session> out of the data root, and resume. Verified end to end through T3 Code's Muse provider.

Related: #60 (view stops projecting mid-run), #94 (view ahead of journal after a kill).

Version and environment

• Muse Code 1.4.4-R5419.1, stable channel, auto-updated by the launcher from 1.4.3-R5018.1. Both host binaries were used for the bisect.
• Client: T3 Code 0.0.46-nightly (bundles @muse-code/sdk 1.4.2). The bisect used a bare JSON-RPC client over muse serve stdio, with the same calls T3 makes: initialize, session/resume {excludeItems: true}, turn/start.
• Ubuntu 24.04.5 LTS, x86_64.