[Bug]: Muse thread stays "Working" forever when Muse cannot stream the session (resume returns projectionUnavailable; session/closed ignored) #17804

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server (packages/provider-muse)

Steps to reproduce

1. Have a Muse thread whose Muse session has no live view on the host. We hit this after Muse auto-updated from 1.4.3 to 1.4.4 between two turns of a long thread (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) meta-models/muse-code-sdk#100). Muse-side Fix ChatView header overflow for long thread titles #60 and Scope DiffPanel patch cache keys by theme #94 leave a session in the same state.
2. Send a message in the thread.

The adapter can be shown the same state without T3: on that session session/resume {excludeItems: true} returns viewCursor: "" and history: {"mode": "none", "noneReason": "projectionUnavailable"}, and turn/start is still accepted.

Expected behavior

T3 notices that Muse cannot stream this session, and either fails the run with a clear error or recovers. Any of these would do:

• when session/resume returns an empty viewCursor or history.noneReason: "projectionUnavailable", fail before turn/start;
• handle session/viewHealthChanged;
• when session/closed or session/statusChanged → notLoaded/idle arrives while a turn is active, reconcile with session/read (Muse has the finished turn) and settle the run.

Actual behavior

The run shows Working/thinking forever. Muse runs the turn and finishes it; the answer is in the session's session.jsonl. T3 receives no notification for the turn: no turn/started, no item/*, no turn/completed. Thirty minutes later Muse unloads the session, and session/closed (reason idle) plus session/statusChanged (notLoaded) do reach the provider event log. T3 still keeps the run active. Stop then fails with Muse turn/interrupt failed: session … is not loaded on this host. The run only ends when the server restarts and marks it cancelled.

Two of our runs sat like this for 7 h and 3 h 20 min. The user never saw either answer.

Reading the bundled adapter (provider-muse/src/server/adapter.ts): register() decodes the session/resume result but does not look at viewCursor or history; handleNotification has no case for session/closed, session/statusChanged or session/viewHealthChanged; and a turn only finishes on turn/completed, a compaction item or a host failure.

Impact

Major degradation or frequent failure

Version or commit

0.0.46-nightly.20261010.2922; also seen on 20261009.2873 and 20261010.2908. Bundled @muse-code/sdk 1.4.2; Muse Code 1.4.4-R5419.1.

Environment

Ubuntu 24.04.5 LTS, x86_64; T3 server run as a user service; Muse provider instance in full-access mode.

Logs or stack traces

# provider event log for the thread: last turn events at 16:17Z, then for the next two runs only
[2026-10-10T01:28:41.467Z] NTIVE: {"provider":"muse","method":"session/closed","params":{"reason":"idle","sessionId":"<session>","viewCursor":""}}
[2026-10-10T01:28:41.467Z] NTIVE: {"provider":"muse","method":"session/statusChanged","params":{"sessionId":"<session>","status":"notLoaded","viewCursor":""}}
[2026-10-10T08:17:16.745Z] NTIVE: {"provider":"muse","method":"session/closed","params":{"reason":"idle","sessionId":"<session>","viewCursor":""}}

# boot-service.log on Stop
ProviderAdapterInterruptError: Failed to interrupt muse provider turn provider-turn:provider:muse:native-turn:muse%3A<session>%3A<turn>.
  [cause]: ProviderAdapterProtocolError: muse provider protocol error: Muse turn/interrupt failed: session <session> is not loaded on this host.

Workaround

Stop every Muse host that has the session loaded, then move ~/.local/share/muse/sessions/.msp-view-v1/<session-id> out of the data root. On the next message Muse rebuilds the view (about 10 s for about 12k records) and the thread streams normally again. Answers Muse produced while the view was missing are in session.jsonl, but T3 does not backfill them.