Oversized transcript invocation blocks Desktop session and Host recovery

[myxtype]

What happened

A valid long-running Desktop task can produce more RuntimeEvents in one invocation than the transcript reader's 8,192-event limit. A transcript tail open then returns persistence_failed / “Session transcript is unavailable”. When Desktop replaces the local Runtime Host, restoring the observed session fails on the same transcript, leaving the Host in a reconnect loop and making other Host-backed actions unavailable.

This is the functional recovery problem behind the diagnosability gap in #5572. The merged diagnostic PRs #5573, #5600, and #5601 record the cause but do not make an oversized invocation readable or prevent the reconnect loop.

How to reproduce

1. Produce a single Turn invocation with more than 8,192 RuntimeEvents through a long run with many model-thinking and tool events. The records can be valid; malformed JSON is not required.
2. Open its transcript tail, or reconnect Desktop while that session is observed.
3. RuntimeTranscriptQuery.events() refuses event 8,193 with RuntimeTranscriptOversizedTurnError. The bootstrap path maps the error to persistence_failed; observation restoration then fails.

In a read-only diagnostic reproduction, one invocation with approximately 9.2k events fails at the 8,192-event limit. Another session with a similar total event count split across several shorter invocations reads successfully. SQLite integrity_check returns ok. No customer data or raw diagnostic files are attached.

Expected behavior

A single oversized but valid invocation should not make the session transcript or the entire Desktop Host unavailable. Preserve access to the rest of the session and report any bounded omission explicitly. Host recovery should isolate this session/read failure rather than repeatedly failing to become ready. Please add regression coverage for an invocation exceeding the source-event limit, including reconnect/observation restoration and a multi-invocation control case.

The issue discussion in #5572 suggests a Turn-aligned placeholder for an oversized invocation or write-side prevention before the limit is reached. Simply increasing the constant would postpone the failure for longer runs.

Environment

• Code-level reproduction with the transcript storage query used by current main; no packaged Apache Maka release or OS-specific behavior was tested.
• The 8,192-event guard is present in current main: packages/runtime-host/src/server/session-transcript-reader.ts derives TRANSCRIPT_SOURCE_MAX_EVENTS from TRANSCRIPT_TURN_MAX_MESSAGES * 2, and packages/storage/src/runtime-transcript-query.ts enforces it per invocation.
• This report contains only aggregate technical facts; customer paths, session IDs, prompts, Skill files, credentials, screenshots, and database contents are intentionally omitted.

[Dante-dan]

I propose handling oversized but valid transcript invocations at the transcript reader, where an invocation is projected for paging. When a source-event or presentation-size limit is reached, return one bounded, clearly labeled placeholder for that invocation and advance using its recorded ordinal extent. That would leave the surrounding session readable without silently presenting a partial invocation. I would keep malformed/incomplete event diagnostics as hard failures, rather than treating every projection error as a size limit.

I would also make Desktop Host replacement isolate a transcript-seed failure to the affected observation, so that another healthy session can reconnect and the Host can become ready. The size placeholder should prevent this specific failure in the usual path; the isolation covers a remaining per-session read failure without masking a Host-wide startup error.

The basis is the current RuntimeTranscriptQuery.events() guard at event 8,193, the reader's separate presentation limits, and the restore path that currently rejects candidate startup when an observation cannot seed. #5572 corrected the limit boundary and noted that a page ending before the oversized invocation can still read. The merged #5573, #5600, and #5601 changes improve diagnostics but do not restore access to a valid oversized invocation. I have inspected these paths; I have not independently reproduced the reported 9.2k-event session or tested a packaged Desktop build.

After assignment, I would add focused regressions for 8,192 versus 8,193+ events, an equal total spread across smaller invocations, paging in both directions around the placeholder, and Host replacement with one affected and one healthy observation. Then I would implement the narrow recovery behavior and run the affected storage, Runtime Host, and Desktop suites plus repository checks. Feedback on the placeholder semantics is welcome.

[Dante-dan]

take