fix(server): Claude workflow members stream their thinking and tool calls into their threads#20856

🟠 High Adapters/ClaudeAdapterV2.ts:4757

A completed workflow member's transcript is permanently marked fully read after the first chunk containing assistant text, so later transcript chunks—and their final answer or tool results—are omitted. readWorkflowAgentTranscript can return a cursor before EOF, but this condition sets finalTranscriptRead based only on textShown; drain the transcript to EOF or check the reader's truncated flag before marking it complete.

Fixed in c05bed4. The settled read now repeats until the reader reports no complete lines left past its 512 KB cap, and finalTranscriptRead is set only once the transcript was read to its end. The reader's truncated also now means only "more complete lines past the cap", not "a half-written last line". New case: "reads a settled workflow member's transcript to its end past the read cap", with about 1.3 MB of replies before the final answer. On the previous head it fails with expected [ …(62) ] to have a length of 81 but got 62.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Keep reading truncated transcript data.

readWorkflowAgentTranscript returns after one capped read and drops truncated. The adapter allows up to three settled reads while the coordinator runs, plus one final read after the coordinator is no longer running. A sufficiently large backlog can still remain unread when projection stops. If the unread data contains the final reply, an earlier textShown value can suppress the partial-answer fallback.

Compare file identities by dev and ino. file.identity !== cursor.identity compares object references, because each read creates a new identity object.

✅ Addressed in commit 9350032

Both points are already handled on the current head, c05bed4. This review was against dd9d609.

• Truncated reads: each projection now keeps reading until the reader reports no complete lines past its 512 KB cap. That covers live reads while a member runs as well as settled reads. finalTranscriptRead is set only once the transcript was read to its end, so a backlog can't be left behind when projection stops. "reads a settled workflow member's transcript to its end past the read cap" covers it with about 1.3 MB before the final answer.
• Identity comparison: nothing compares identity objects by reference. readContainedWorkflowFile compares dev and ino field by field when deciding whether to resume from the cursor, and the drain loop compares numeric offsets.

@juliusmarminge, you’re right. I checked c05bed4d0f.

• The adapter drains capped reads for both running and settled members. finalTranscriptRead requires transcriptDrained.
• readContainedWorkflowFile compares dev and ino values. The drain loop compares numeric offsets, not identity objects.
• The regression test asserts that all 81 replies appear, including the final answer after about 1.3 MB. I inspected the test but did not run it.

My finding does not apply to the current head. I withdraw it. The identity-reference claim was incorrect.

✅ Review thread resolved.

You are interacting with an AI system.

Both points were already handled before this comment. CodeRabbit confirmed that in its own follow-up, and the thread is resolved and outdated.

• Truncated reads: projectClaudeWorkflowMembers keeps reading while a read is truncated and its cursor advances (transcriptDrained = !read.value.truncated || !advanced), so the loop sits in the adapter rather than readWorkflowAgentTranscript. The test "reads a settled workflow member's transcript to its end past the read cap" covers it with about 1.3 MB written ahead of the final reply.
• Identity comparison: nothing compares identity objects by reference. readContainedWorkflowFile compares dev and ino (workflowFileRead.ts), and workflowAgentTranscript.test.ts covers an inode swap and a shrunk file.

@juliusmarminge, you’re right. The prior follow-up already confirmed both points. My finding remains withdrawn. Sorry for the repeated follow-up; no further action is needed.

✅ Review thread resolved.

You are interacting with an AI system.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Keep the settled-member flush read enabled after text projection.

When an earlier transcript line sets textShown, awaitingReply() becomes false. The settled member then skips the 500 ms delayed drain(). The same read sets finalTranscriptRead: true, so later coordinator-ended frames do not read the transcript again. A final assistant line written during that interval can be omitted.

Remove !textShown from the flush guard while preserving the !resultShown check.

✅ Addressed in commit 182365d

Real gap, fixed in 182365da33, but not with the suggested one-line change.

Dropping !textShown would make every settled member that has already answered wait 500 ms when the workflow ends, including members whose reply is already on screen. The guard now tracks whether the transcript reached the end of the member's turn: an assistant line whose stop_reason is neither tool_use nor null. Text written before a tool call no longer counts as the reply, and a member that has finished its turn doesn't wait.

The late-flush test now runs twice, with and without text before the tool call. Without the fix, the second case fails with expected [ 'Reply with exactly: A2', …(1) ] to deeply equal [ 'Reply with exactly: A2', …(2) ].

@juliusmarminge Thanks for the clarification. The turnEnded guard addresses the gap more precisely than my suggested change.

The supplied code keeps the delayed read enabled after text before a tool call. It skips the wait when the transcript already contains the turn-ending assistant line. The two test cases cover the reported gap without adding an unnecessary delay for completed replies.

✅ Review thread resolved.

You are interacting with an AI system.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Keep transcript turns open when stop_reason is absent.

readWorkflowAgentTranscript accepts assistant lines without message.stop_reason. The CLI-shaped member fixture uses separate thinking, tool-use, and reply lines with that field omitted. When the thinking line is read first, isClaudeTranscriptTurnEnd returns true. If the member settles before the reply is appended, awaitingReply() becomes false, so the 500 ms flush does not read the late reply. The member thread can therefore lose its final reply. Treat an absent stop_reason as an open turn, while preserving the existing tool_use and null handling.

✅ Addressed in commit 5f8f181

Fixed in 5f8f181397, taking the suggested direction.

No Claude Code transcript actually leaves stop_reason out: none of the 42,833 assistant lines in the workflow and subagent transcripts on this machine do. Only hand-written test fixtures did. Still, keeping the turn open costs at most the 500 ms flush window, and ending it early can lose the reply, so a turn now ends only on a line whose stop_reason is a string other than tool_use.

The fixtures that stood in for a member's reply now carry end_turn, as real replies do. The late-flush test gained a third case, with a line without a stop reason before the reply. Without the change that case fails with expected [ 'Reply with exactly: A2' ] to deeply equal [ 'Reply with exactly: A2', …(1) ].

@juliusmarminge Thanks for the clarification. My original comment should have distinguished hand-written fixtures from observed Claude Code transcripts.

The supplied implementation now ends the turn only when stop_reason is a string other than "tool_use". This keeps absent and null stop reasons open. The reported regression case covers the late reply after a line without a stop reason.

✅ Review thread resolved.

You are interacting with an AI system.