Re: [I] Desktop: task refresh fails with opaque persistence_failed; the real transcript error is discarded [maka]

["MoonOld (via GitHub)" <gi...@apache.org>]

MoonOld commented on issue #5572:
URL: https://github.com/apache/maka/issues/5572#issuecomment-5760809700

   **Root cause identified** — this failure is deterministic, not transient.
   
   The throw comes from the storage layer, which defines a dedicated error for exactly this condition, but **nothing in production code handles it**:
   
   `packages/storage/src/runtime-transcript-query.ts:430`
   
   ```ts
   if (count === limits.maxEvents) {
     throw new RuntimeTranscriptOversizedTurnError(
       `Turn ${invocationId} holds more RuntimeEvents than a transcript page may read`,
     );
   }
   ```
   
   `RuntimeTranscriptOversizedTurnError` is referenced only by tests and the test-only in-memory runtime (whole-repo grep). It therefore falls straight into the catch-all in `session-continuity-coordinator.ts` and surfaces as `persistence_failed`.
   
   ### Triggering condition: a single oversized Turn
   
   The cap comes from `session-transcript-reader.ts:53`:
   
   ```ts
   const TRANSCRIPT_TURN_MAX_MESSAGES = 4_096;
   const TRANSCRIPT_SOURCE_MAX_EVENTS = TRANSCRIPT_TURN_MAX_MESSAGES * 2; // 8192
   ```
   
   and is passed to storage as `maxEvents` by `readRun`.
   
   Counting the reporter's `runtime.sqlite`, exactly **one** Turn in the whole workspace exceeds it — the runner-up is only 5944, so this is not a systemic size problem, it is a single long autonomous run that grew past the cap:
   
   | | |
   |---|---|
   | Session | `4974ff21-acfc-41ae-bdee-f1678734f638` |
   | Turn (invocation/run) | `9eb0707d-4a59-42c4-a9fb-9eb30e78937d` |
   | Events | **9382** (over 8192 by 1190, ~14.5%) |
   | Span | 2026-09-21T10:14:43Z → 11:00:42Z (~46 min inside one Turn) |
   | Composition | 441 `function_call`/`function_response` pairs (441 tool calls), 7618 `runtime_fact`, 220 `text`, 219 `thinking` |
   
   ### Why it takes down the whole session
   
   `readRun` pushes **every** event of the Turn into the projection, and paging in `scan()` walks Turn by Turn (`run.firstOrdinal … run.lastOrdinal`). Any page overlapping that Turn must project all of it, so it always throws.
   
   The timeline matches: the Turn ended at 11:00:42Z, and the failing refreshes are at 12:18Z and 12:43Z.
   
   **Impact:** the session's transcript is permanently unreadable and retry can never succeed — yet the copy shown is "try again later". This is a concrete instance of the retryable-vs-deterministic point in the issue body.
   
   ### Note on how the limit is derived
   
   `TRANSCRIPT_SOURCE_MAX_EVENTS` is derived from a **message** budget (`TRANSCRIPT_TURN_MAX_MESSAGES * 2`), but a Turn's **event** count is not bounded by its message count (441 tool calls → 9382 events). The two quantities do not share a source, which is how a Turn can pass the message check and still blow the event check.
   
   ### Fix directions
   
   1. Log the real error, as described in the issue body.
   2. Degrade instead of failing the whole session: project what fits and append a truncation notice — there is precedent, the read model already reduces large Bash streams to a bounded terminal preview.
   3. Larger change: let a page cut *inside* an oversized Turn at an ordinal boundary rather than requiring Turn boundaries; this touches the `endsAtTurnBoundary` / spliceability assumptions.
   4. Write-side prevention: force a new Turn/invocation once a Turn's event count crosses a threshold.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org