AI agent conversations: provider bodies in the view, and files over HTTP

[wu-sheng]

Two things for the AI agent conversations the SkyWalking AI Sessionizer lands:

1. the provider bodies joined to their calls in the asz.view document OAP serves — an llm.call step names where its request and its response landed, and the document never carries the bodies;
2. a new route, GET /ai-agent/conversations/{conversation}/v1/files, which serves the raw Session Data files of one session by (session, seq), at most 32 a request, as application/vnd.skywalking.asz.files+ndjson: a line naming each file, then exactly the bytes it names.

Together they let a page show the exact prompt a model call sent and the answer it got, loading only the files that call points at. The protocol side is apache/skywalking-query-protocol#175; the reader is apache/skywalking-horizon-ui#165.

The join

Ported from the Sessionizer's own reader, rule for rule. A response joins by the message id it carries, which is the call's own. A request names no call, only the request before it and its prompt, so it joins to the call of its stream whose previous call's response carries that request id and whose prompt is the one it names, when exactly one request and exactly one call carry the pair. A synthetic call takes part in no join, a body landed twice is one body, and no request joins in a stream whose landed lines have a gap. Nothing is joined by position or by time.

The route

• Requires service, instance, session and at least one seq; at most 32, each a positive whole number. coldStage selects cold storage.
• Framing is by declared byte count: a non-empty file that does not end with a newline is followed by one, which is not part of it. The naming line carries file, seq, lines, bytes, digest, and copies where the read saw that seq more than once.
• gzip when the caller takes it, written a chunk at a time so nothing compressed accumulates.
• Errors are RFC 9457 problem documents — including a request that runs out of time, which previously took the server's own plain-text 503.

Bounds and cancellation

• A conversation's rounds and files are read readWindow at a time (16), and every read asks whether the caller is still there, so an abandoned request stops instead of running to completion.
• fileRange looks for the newest intact round one round at a time, as before, but stops after 16 rounds instead of descending to round 1. A head round that does not parse used to cost one storage read per round — measured at 100,001 reads for one request on a long chain, all of which ran on after the client had gone.
• Record decoding follows the Sessionizer's: a record whose own fields do not decode stops that file where its reader stops, and a null in flags decodes to an empty string rather than throwing. What is inside parts, dropped and usage is deliberately not inspected — Go ignores fields it does not declare, and refusing a record it accepts would hide that record and every one behind it.
• The chain check coalesces absent sequences into runs as it finds them, instead of one entry per sequence, and its counter can no longer wrap.

Settings

Five, in the order an operator meets them: conversationListMaxLimit (renamed from maxListLimit, and its comment now says plainly that it counts rounds, not conversations, so a busy conversation spends the budget of the quiet ones), viewRequestTimeout, readWindow (the former fileReadWindow and roundReadWindow, which were the same idea with the same value), maxResponseBytes (BanyanDB alone accepts it; Elasticsearch and JDBC bound a read by hits and by rows) and maxFileBytes.

Testing

64 module tests pass on a clean build, including the e2e case under test/e2e-v2/cases/ai-agent/, which pushes real Sessionizer output, checks seven concrete request/response joins, and calls the files route with the pinned CLI, verifying the digest each naming line advertises.

Reviewed by GPT-6 across four rounds; every finding is fixed in this commit. Two are worth naming: the first version of the bounded fileRange read a window of round bodies, which fetched sixteen to find one in the healthy case and could lose a readable duplicate when a storage capped the window — it is now the original per-round read with a bound; and a JDBC change that claimed to bound memory did not, because the driver buffers the result regardless.