fix(web): keep ReadMediaFile media rendering after session resume - #1552
Merged
Conversation
Tool-role messages reached the snapshot/messages REST projection with their content flattened to text, dropping image/video/audio parts, so a ReadMediaFile result rendered as an image while streaming but fell back to a generic tool card after a reload. Pass the raw content parts through when a tool result carries media, matching the live tool.result event shape the web client already parses.
🦋 Changeset detectedLatest commit: 762cde4 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
commit: |
Collaborator
Author
|
Codex Review: Didn't find any major issues. Breezy! Reviewed commit: ℹ️ About Codex in GitHubCodex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback". |
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Related Issue
No tracking issue — this is a clear, reproducible rendering bug; the problem is explained below.
Problem
In the web UI, a
ReadMediaFiletool call renders as an image card while the session is streaming, but after resuming the session or reloading the page it degrades to a genericReadMediaFiletool card — the image is gone.The two delivery paths disagree on the tool-result payload shape:
tool.resultevent carriesoutputas the raw kosong content-part array ([text('<image path="…">'), image_url, text('</image>')]), which the web client parses into the media card.''), sooutputarrived as"<image path=\"…\"></image>"— the media bytes never left the server, and the client fell back to the generic card. (The wire log on disk keeps the full parts; they were dropped only at projection time.)What changed
toProtocolMessage, used by both the snapshot and messages endpoints), a tool result that carries image/video/audio parts now passes the raw content-part array through astool_result.output— the same shape the live event stream already sends. Text-only results keep the historical flattened string, so the common case is byte-identical. The protocol field isz.unknown()and the web client already parses both shapes, so no schema or client changes were needed.ReadMediaFileresult surfaces as a media card.This fits Kimi Code because it removes the divergence at its source — one canonical payload shape for both delivery paths — instead of adding a second, lossy recovery path in the client. Old sessions are fixed retroactively since the media bytes were always preserved in the wire log.
Checklist
gen-changesetsskill, or this PR needs no changeset.gen-docsskill, or this PR needs no doc update. (Bug fix only — no user-facing behavior to document.)