fix(kosong): degrade unsupported base64 image/video to placeholder instead of throwing - #1
Closed
xpzouying wants to merge 1 commit into
Closed
fix(kosong): degrade unsupported base64 image/video to placeholder instead of throwing#1xpzouying wants to merge 1 commit into
xpzouying wants to merge 1 commit into
Conversation
…stead of throwing An image or video whose base64 media type Anthropic does not accept (e.g. avif) threw during request serialization. Since history is resent every turn, that throw failed every request and even blocked compaction from recovering, hanging the session. Return a placeholder text block carrying the mime instead, mirroring the existing audio degradation.
Owner
Author
|
Closing as redundant: upstream MoonshotAI#1536 (merged 2026-07-10) already fixes this comprehensively — a single image-format policy enforced at every ingestion point (ReadMediaFile refuses with a conversion command; MCP/REST/ACP replace with a text notice; turn.prompt/steer backstop) plus a 400-recovery media-stripped resend. This branch's change (degrading the Anthropic serializer throw) targets a path MoonshotAI#1536 already guards, and would remove the throw that MoonshotAI#1536 relies on as a recovery tripwire. |
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
1 participant
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 issue — the problem is described below.
Problem
Reading a media file whose base64 media type Anthropic does not accept (e.g. an
.avifmislabeled.jpg) hangs the session.ReadMediaFilesucceeds and the image lands in history as a tool result; on the next request the Anthropic serializer throwsUnsupported media type for base64 imagewhile converting that history to the wire format. Because the whole history is resent every turn, every subsequent request hits the same throw — andcompaction, which serializes the same history to summarize it, fails the same way, so the session cannot even recover on its own.Only the Anthropic adapter throws here; it already degrades unsupported audio to a placeholder text block. Image and video should do the same.
What changed
In
imageUrlPartToAnthropic/videoUrlPartToAnthropic, an unsupported base64 media type now returns a placeholder text block carrying the mime (e.g.(image omitted: unsupported format image/avif)) instead of throwing, mirroring the existingOMITTED_MEDIA_PLACEHOLDERaudio path. History is left untouched — the placeholder is produced only at serialization time. The malformed-data-URL throw is kept (that is a real error). Tests updated and added for the image/video unsupported-format paths.Checklist
gen-changesetsskill, or this PR needs no changeset.gen-docsskill, or this PR needs no doc update.