fix(acp): preserve file attachment metadata during session replay #6339
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.
Problem
When a user attaches a file (e.g., a JSON config file) via an ACP client, the file displays correctly in the initial session. However, when the session is reloaded (via
loadSession), the file attachment appears as plain text instead of as a proper attachment with filename and metadata.Before this fix:
firebase.json→ shows as attachment ✓Root Cause
The ACP
promptfunction was storing text resources as plaintextparts, which preserved the content for the LLM but lost the file metadata (filename, mimeType). TheprocessMessagefunction (used for session replay) had no handler forfileparts at all.Solution
This PR fixes the issue with a two-part approach:
1. Store resources as file parts (
agent.ts)Text and binary resources are now stored as
fileparts with base64 data URLs:This preserves the filename and mimeType for proper replay.
2. Handle file parts during session replay (
agent.ts)Added handling in
processMessageto replay file parts as ACP blocks:imageblocksresourceblocks (decoded from base64)3. Decode text-based files for LLM compatibility (
message-v2.ts)Since file parts now contain base64-encoded content,
toModelMessagedecodes text-based files before sending to the LLM:Binary files (images) are sent as file parts for multimodal models.
Alternatives Considered
Store text resources as text parts (original behavior): Simpler, but loses file metadata for replay.
Save attachments to disk and let LLM use
readtool: Would require saving files to disk first, and thereadtool doesn't work with data URLs.Store both text part and metadata separately: More complex data model changes.
The chosen approach is minimal and preserves both LLM compatibility and proper ACP replay.
Additional Fixes
"image"elsestatements, replaced deprecatedatob/btoawithBufferTesting