[Bug]: New threads still stay blank after a pre-create /bounded 404 on 0.1.8 nightly (regression of #27443)#31681

opened6d agobyKkrymancer

Note

🤖 Claude Opus 5.5 responding on behalf of krymancer

New threads still stay blank after the first message on 0.1.8-nightly.20261105.4234. This is the same bug as #27443, #27482, #27641, #27623 and #27797. Those issues are all closed, but the fix PR #27827 is still open and not merged. The shipped client still has the faulty code path.

Before submitting

I searched existing issues and did not find a duplicate. All earlier reports are closed, and none of them tracks the regression on 0.1.8.
I included enough detail to reproduce or investigate the problem.

Area

apps/web (client runtime: packages/client-runtime/src/state/threads.ts)

Steps to reproduce

Open a new, empty thread in a project, or the first thread in a new project.
Wait a few seconds, then send the first message.
This happens intermittently. It only happens when the client requests the thread's /bounded snapshot before thread.create is committed.

Expected behavior

The user message, the running turn and the assistant reply are shown live.

Actual behavior

The thread view stays blank, or shows only the "Worked for X" row, for the whole run. The agent runs and saves its reply on the server. Fully quitting and reopening the app shows the conversation.

Impact

Major degradation or frequent failure

Version or commit

0.1.8-nightly.20261105.4234

Environment

Linux (CachyOS) desktop, local built-in server, claudeAgent provider.

Logs or stack traces

From server.trace.ndjson on 2026-11-05 (UTC). The snapshot 404 comes first. The thread is created 5.5 s later. The client does not subscribe to the thread until the app is reopened 137 s later:

1	20:50:00.830 http.orchestration.loadThreadSnapshotWindow Failure
2	EnvironmentResourceNotFoundError (thread_not_found)
3	20:50:06.387 orchestrationV2.dispatch.threadCreate thread_id=394c4fa8-c714-4292-b7e4-9f1fb155cf5f
4	(no ws.orchestrationV2.subscribeThread for 394c4fa8 while the turn runs)
5	20:52:23.484 ws.orchestrationV2.subscribeThread thread_id=394c4fa8-… (after reopening the app)

The current trace logs contain four thread_not_found failures from loadThreadSnapshotWindow.

The shipped bundle (client/assets/runtime-*.js) still has the sequence described in #27827:

ThreadSnapshotLoader.load maps EnvironmentResourceNotFoundError to { _tag: "missing" } and logs "Bounded thread snapshot not found over HTTP; treating the thread as deleted."
In EnvironmentThreadState.makeSubscribeInput, the missing case calls setDeleted() and parks.
The guard at the top of makeSubscribeInput returns right away for status === "deleted", so resubscribe never recovers once the thread exists.

Workaround

Fully quit and reopen the app.

JJulius Marminge10h ago

Fixed by #25919, now on main: After a new thread's initial /bounded request returns 404 before creation commits, the mounted client now retries until the thread exists, loads its messages, and subscribes without requiring an app restart.