analysis pagination can exceed the capability retained-result limit

[andreasronge]

Summary

Large analysis collection pages can pass the snapshot query's encoded-JSON byte check and then fail at the Kernel capability boundary with provider_result_limit, because the dispatcher measures retained BEAM size instead.

This keeps the debugging evidence layer unavailable on exactly the map-heavy runs that most need analysis.

Historical evidence

The original inspection-analysis-v2 API forced limit: 100. Two independent 40-turn live runs reproduced the failure for model_exchanges while smaller runs and sibling collections succeeded. Those exchanges are derived from paired capability-input / capability-output records, so bypassing the analysis profile requires reimplementing its correlation logic.

The old API no longer exists. Current analysis/read accepts a caller-controlled limit from 1 through 100 and exposes cursors. That removed the literal "no caller control" defect, but not the boundary mismatch.

Current cause on main

• InspectionQuery and TraceLog fit pages using byte_size(Jason.encode!(page)).
• InspectionSnapshot applies a retained-size check only to the singular terminal result.
• Dispatcher checks every successful capability result with RetainedSize.bytes_with_cap/2 against capability_result_bytes.

A map-heavy page may therefore be accepted by its source owner and rejected only after returning from the capability callback. Lisp projection cannot recover because the capability never returns a value.

Expected contract

A requested page limit is an item-count upper bound. Before a snapshot publishes a page, the complete returned page, including snapshot metadata, must fit both:

1. its encoded JSON byte ceiling; and
2. the retained-size ceiling enforced by the dispatcher.

If the requested prefix does not fit, pagination returns the largest non-empty fitting prefix and an advancing cursor. If one individual item cannot fit, the query returns result_limit_exceeded without a stalled cursor.

Scope

• Use one shared encoded-and-retained result-budget policy.
• Apply it to private inspection and canonical trace pagination.
• Apply the same policy to bounded RunAnalysis singular and aggregate results.
• Keep the dispatcher as the final authority.
• Do not raise limits, truncate fields, change cursor identity, widen authority, or add chunking for an intrinsically oversized individual item.

Acceptance

• A network-free 40-exchange cumulative-conversation fixture reproduces the old provider_result_limit failure before the fix.
• Default analysis/read returns a non-empty bounded page and cursor after the fix.
• Following cursors recovers every exchange exactly once.
• limit: 1 succeeds when the individual item fits.
• Every returned page fits both encoded and retained ceilings.
• Existing individually-oversized-item failures remain stable.
• Equivalent canonical trace pagination cannot outrun the dispatcher boundary.

[andreasronge]

Confirmed size-dependent, which sharpens this. The same query on two runs from the same app:

run	turns	model exchanges	(inspection/model-exchanges r nil)
checkout-5xx	6	5	returns 5
schema-migration-stall	40	40	result_exceeded

So the query is not broken — it works until a run gets big enough to be worth analyzing, and then becomes unreachable with no caller-side recovery. The cursor cannot help, because obtaining a cursor requires page 1 to succeed first.

That is the shape worth fixing: the failure lands exactly on the runs where reading the conversation matters, and a caller who wants a small summary across many exchanges has no way to ask for one.

[andreasronge]

Reproduces on a second, independent large run

Same failure on a different 40-turn run (332-record corpus, live model,
model_exchanges 40, 79-message final transcript):

{"capability_activity": true, "capability_failure": true, "kind": "failed",
 "message": "private evaluation failed; diagnostic withheld by the private result policy"}

Every sibling query works on the same artifact, including
inspection/capability-calls paginated to all 364.

One detail for whoever fixes this, because it decides where the workaround
cannot be: the raw inspection artifact contains no model-exchange records at
all. Its record_type census is

capability-input 404, capability-output 404, mcp-request 364,
mcp-response 364, evaluation-source 40, prelude-source 11

The profile derives the 40 model exchanges from the llm-request
capability-input/capability-output pairs. So the mapping from the stored
record to the query lives only in the profile, and reading the raw file is not a
workaround that another tool can reproduce without reimplementing that mapping.

(For this analysis the transcripts were recovered by hand from
capability-input payloads where payload.name == "llm-request", which is that
reimplementation.)

[andreasronge]

Claimed for implementation on agent/fix-analysis-result-budget in the current Codex worktree. Plan review completed with two independent-review attempts. The implementation will add failing snapshot and full analysis-session regressions first, then align inspection and trace page fitting with the dispatcher retained-result boundary. Assignment is advisory; the branch and eventual draft PR are the artifacts.

[andreasronge]

Implemented in draft PR #1410: #1410

The fix sizes the complete final trace/inspection page—including snapshot metadata—against both encoded and retained-size ceilings, treats limit as an upper bound, and returns the largest fitting prefix with a followable cursor. It also adds a size-independent run existence probe so an oversized run summary cannot block a smaller filtered read.

Verification completed: mix precommit; docs with warnings as errors; pre-push core tests (6,289), static analysis/Dialyzer, release verification, and Viewer tests. Review limits were honored: 2 plan reviews and 3 implementation review invocations; the final cumulative review found no actionable issues.