[Bug]: Session message tail disappears mid-generation on v0.13.10 stable (regression of #1747)

[MariusWilsch]

Symptom

Message tail disappears from the visible chat during or shortly after agent generation. The bug occurs spontaneously on active sessions — no navigation, minimization, or browser close required to trigger it. Hard reload of the page restores the full message history, confirming server-side persistence is intact. This is the same surface as #1747 ("Last 2 messages disappear from chat thread"), which appears to remain unfixed despite multiple fix attempts.

Versions tested — bug persists across all

Version	Released	Fix targeting this surface	Status
v0.13.4 / v0.13.5	2026-05-07 / 2026-05-08	(original report on #1747)	Bug present
v0.13.6	2026-05-12	#1749 "preserve live session state" + #1750 "preserve live tail messages" (claims to close #1747)	Bug persists per @platem 2026-05-13
v0.13.7 / v0.13.8	2026-05-13	(no further session-render fixes)	Bug persists per @platem 2026-05-13
v0.13.9	2026-05-15	#1801 "coalesce streaming transcript deltas" (pure perf, no behavior)	Not directly tested
v0.13.10 stable	2026-05-18T18:19Z	#1824 "Fix session transcript reconciliation" + #1831 "harden session streaming and server health"	Bug still reproduces 2026-05-19

Five fix attempts shipped over the past 8 days targeting this exact surface. The bug continues to manifest on v0.13.10 stable.

Reproduction

Hit during a witness walk on a self-hosted OpenWork web deployment pinned to v0.13.10 stable (commit 1cdd52d7d3c13d25c3afe1bb72be54e7107d3c78). The bug is intermittent — not every generation triggers it — but appears reliably across multiple walks. Specific session captured today: ses_1c1968690ffepavaBLDwmYq4r1.

Approximate steps:

1. Open a session in the self-hosted web deployment, ensure agent is configured with skills/MCPs.
2. Submit a user message, let the agent generate a multi-part response (with tool calls + final text).
3. Continue the conversation across 3–5 message exchanges.
4. Observe — at some point during or shortly after a generation completes, prior messages in the tail vanish from the visible chat without user action.

Sometimes the disappearance is partial (last 2 messages absent, like the original #1747 framing), sometimes it leaves only the first agent message visible. Server-side state has been verified intact across multiple walks via direct inspection of /data/opencode/storage/session_diff/ses_*.json — the data is always present on the server; the SPA's render of it is what loses messages.

Expected behavior

Messages persist in the visible chat once written. Stream completion does not cause prior tail messages to vanish.

Actual behavior

Message tail vanishes from the rendered chat. Hard reload of the page restores the full history (confirming the loss is purely in the SPA's render layer, not in any persisted state).

Bounded evidence

Layer	State	Verified
Server-side session storage	Has full history	✅ Walk-6 verified via docker exec ... cat /data/opencode/storage/session_diff/ses_1de8beeb*.json
SPA render (DOM)	Missing tail messages	✅ Witnessed multiple sessions across multiple walks
Hard reload	Restores full history	✅ Reload from server snapshot brings everything back
HTTP snapshot response (Network tab)	Not yet captured	❌ Will capture on next repro if helpful
React Query transcript cache (DevTools)	Not yet inspected	❌ Will capture on next repro if helpful

Environment

• Deployment: Self-hosted OpenWork web (Caddy + pnpm build:web of @openwork/app)
• Browser: Chromium-based (Playwright agent-browser driver, also reproduced manually in standalone Chrome)
• Pin: OpenWork SPA at v0.13.10 stable (1cdd52d7d3c13d25c3afe1bb72be54e7107d3c78), orchestrator at openwork-orchestrator@0.13.3 (npm)
• Session protocol: Server-side session-diff storage, SSE event stream, snapshot-based hydration via getSessionSnapshot

Note on orchestrator version: we are currently running openwork-orchestrator@0.13.3 while the SPA is at v0.13.10. This may or may not be relevant — the prior fix-set (#1749, #1750, #1824, #1831) is all SPA-side, so a version-aligned orchestrator should not change behavior. Flagging the drift for completeness.

Distinct from cold-cache rehydration

For clarity: this bug is not about closing the browser and revisiting the session URL. Browser close + revisit is one of the recovery paths users have used to attempt to surface the messages back; sometimes it works (as the cache rehydrates from server snapshot), sometimes it does not. The bug itself is the spontaneous mid-generation or post-generation tail disappearance on active sessions.

Distinct from #1747?

Believed to be the same root cause as #1747 — the title of #1747 ("Last 2 messages disappear from chat thread") matches this surface precisely. #1747 was closed with #1750 as the claimed fix, then re-confirmed unresolved by @platem on 2026-05-13 on v0.13.8. Filing this as a fresh tracker rather than reopen-request so it has explicit v0.13.10-stable evidence + the multi-fix-attempt history that the closed #1747 thread doesn't surface.

Collaboration

Happy to capture HTTP snapshot response + DOM message count + React Query transcript cache state next time the bug reproduces, if maintainers want pinpointed data on which layer drops the messages. Will also re-test on each v0.13.11-alpha drop and update if anything changes.

References

• 🐛 #1747 — original bug report, closed-not-fixed
• 🔧 #1749 + #1750 + #1824 + #1831 — five fix attempts, all insufficient
• 💬 @platem confirmation v0.13.8 still broken
• 💬 Marius (this reporter) prior repro on v0.13.8 dev SHA

[MariusWilsch]

Empirical repro on v0.13.10 stable + suspected root cause across 3 layers

Tested on self-hosted web deployment pinned to v0.13.10 stable SHA 1cdd52d7d3c13d25c3afe1bb72be54e7107d3c78. Reproduced the spontaneous tail-loss with full evidence + traced the failure mode through the SPA codebase.

Reproduction

Self-hosted OpenWork web (Caddy + pnpm build:web of @openwork/app) on Chromium. Session: ses_1bbfa45deffeMwUThBJVFOlw4c, 3 conversational turns with bulk-data-entry agent.

Time (T0 = turn 3 user msg)	Server state	DOM [data-message-id] count
T+0s	user msg created	6
T+3s	first assistant msg (msg-8) streaming	7
T+6s	msg-8 completed	8
T+6s	second assistant msg (msg-9) created — completed: null	8
T+9s through T+60s	quiescent (no further SSE events)	8
T+~64s	(no user action)	0 (cliff drop)

After cliff:

• Hard F5 reload: DOM stays at 0. (Contradicts earlier framing — soft reload does not restore.)
• Full URL re-navigation (agent-browser open URL): DOM restores to 8, Stop button visible indicating server still reports session as busy.
• Orchestrator API direct query (/workspace/{ws}/sessions/{ses}/messages) confirms 9 items server-side, last one completed: null.

Three-layer root-cause hypothesis

Layer 1 — Opencode runtime creates msg-9 with completed: null, never finalizes

The 2nd-per-turn assistant message gets created on the server but no parts are ever streamed and no completion marker arrives. The SSE event stream goes quiet at this point but the server still considers the session active.

Server-side message timeline (via orchestrator /messages API):

{ "role": "assistant", "created": <T+6.4s>, "completed": null }  // msg-9 — stuck

This appears to be the upstream root cause. Every prior turn's 2nd assistant message completed normally. Why this one didn't is unclear without opencode-runtime logs.

Layer 2 — Transport-level 30s watchdog aborts the SSE connection

apps/app/src/react-app/domains/session/sync/session-sync.ts:618-680

const staleStreamMs = 30_000;
...
watchdogTimer = setInterval(() => {
  if (...retryTimer) return;
  if (Date.now() - lastEventAt < staleStreamMs) return;
  active.abort();        // Abort SSE
  scheduleRetry();       // Reconnect with 1s/2s/4s/8s backoff
}, 10_000);

After Layer 1 leaves SSE quiet for 30 seconds, the watchdog assumes the stream is stuck and aborts. Reconnect cycle then runs through 1s/2s/4s/8s backoffs.

Layer 3 — Reconnect-time session.idle event + non-observer cache subscription clears DOM

When the new SSE connection establishes, opencode emits session.idle because no generation is actively running (msg-9 is created but quiescent server-side).

session-sync.ts:514-520:

if (event.type === "session.idle") {
  queryClient.setQueryData(statusKey(workspaceId, props.sessionID), idleStatus);
  if (input) releaseRetainedSessionSoon(input, entry, props.sessionID);
}

releaseRetainedSessionSoon sets a 10s timer that fires clearTrackedSession, which calls:

queryClient.removeQueries({ queryKey: permissionKey(...), exact: true });

This removeQueries call fires a QueryCache event. The render path subscribes to ALL cache events via:

session-surface.tsx:157-166:

function useSharedQueryState<T>(queryKey: readonly unknown[], fallback: T) {
  const queryClient = getReactQueryClient();
  return useSyncExternalStore(
    (callback) => queryClient.getQueryCache().subscribe(callback),  // ← cache-level subscriber, NOT a query observer
    () => (queryClient.getQueryData<T>(queryKey) ?? fallback),
    () => fallback,
  );
}

This is the critical structural issue. useSharedQueryState subscribes to the cache via getQueryCache().subscribe(callback) rather than registering as a React Query observer. The implications:

1. No active observer → the transcript query has zero observers from React Query's perspective. With default gcTime: 5 * 60_000, the query is eligible for GC after 5 minutes of no observers (not the cause of the 64s cliff, but a related latent issue).
2. Every cache event re-evaluates getQueryData — including unrelated mutations like removeQueries(permissionKey). The fallback chain getQueryData(...) ?? fallback means any moment where the cache returns undefined (eviction, race, etc.) renders EMPTY_TRANSCRIPT (i.e., []).
3. Render path uses mergeSnapshotAndLiveMessages (not reconcileTranscriptMessages) — bypassing the "snapshot must not move transcript backwards" invariant that transcript-reconcile.ts:25 enforces at cache-write time. So even when the cache is correct, the render derivation can produce a backward-moving result.

The combination — Layer 1 leaves a stale message; Layer 2 triggers a reconnect; Layer 3's reconnect-induced cache events fire the non-observer subscriber while the snapshot refetch races with cache eviction — produces the cliff.

Proposed fixes (ordered by surgical scope)

Fix A (1-3 LOC) — Make useSharedQueryState register as a proper React Query observer

Replace the cache-level subscriber with useQuery({ queryKey, enabled: false, initialData: fallback }). React Query then maintains observer count, prevents premature GC, and re-renders deterministically only on data changes (not on every unrelated cache event). No semantic change for callers.

Fix B (~10 LOC) — Use reconcile invariant at render layer too

In session-render-state.ts:deriveRenderedSessionMessages, replace mergeSnapshotAndLiveMessages(snapshotMessages, liveMessages, { appendLiveOnlyMessages: true }) with reconcileTranscriptMessages({ currentMessages: liveMessages, snapshotMessages, reason: "snapshot" }). The invariant ("snapshots must not make transcript move backwards") then holds at render time, not just cache-write time.

Fix C (~20 LOC) — Watchdog should respect uncommitted-tail state

In startSync watchdog (session-sync.ts:669-679), before aborting on staleStreamMs, check whether the last message in the transcript has completed: null (read from cache). If so, the stream may be legitimately waiting for further server events, not stuck. Don't abort; extend the watchdog window.

Fix D — Upstream opencode runtime

Don't leave assistant messages with completed: null indefinitely after creating them. If no parts are about to stream, either skip the create OR mark complete with empty parts immediately.

Recommendation: Fix A is the highest-leverage 1-line surgical fix. It addresses the structural issue that makes the SPA fragile to ANY cache event (not just this specific scenario). Fix C is the right transport-level hardening. Fixes B and D are defense-in-depth.

Evidence

Local repro screenshots + server-side message tree JSON committed at:

• https://github.com/DaveX2001/deliverable-tracking/tree/main/tracking/issue-1733/repro-1844-evidence

Happy to capture additional artifacts (React DevTools QueryCache state during cliff, HTTP snapshot response payload, application vs session_diff server-side files) if maintainers want pinpointed verification of any of the three layers.

Source: 🗒️ Session 1ac9aedd

🤖