Skip to content

Fix: base64-encode UTF-8 code executor output files before saving them as artifacts - #677

Open
AmaadMartin wants to merge 2 commits into
mainfrom
fix/code-execution-output-file-encoding
Open

Fix: base64-encode UTF-8 code executor output files before saving them as artifacts#677
AmaadMartin wants to merge 2 commits into
mainfrom
fix/code-execution-output-file-encoding

Conversation

@AmaadMartin

Copy link
Copy Markdown
Owner

Please ensure you have read the contribution guide before creating a pull request.

Link to Issue or Description of Change

  1. Link to an existing issue (if applicable):
    N/A
  2. Or, if no issue exists, describe the change:
    Problem: postProcessCodeExecutionResult puts File.content straight into Part.inlineData.data. That field is defined to be base64, and FileArtifactService and GcsArtifactService both decode it with Buffer.from(data, 'base64'). A text output file carries raw UTF-8 (File.contentEncoding === 'utf-8'), so the decode silently drops the non-base64 characters and writes a few bytes of noise. hello from script (17 chars) becomes 11 bytes of binary; the artifact is unrecoverable.

Solution: A new helper getFileContentAsBase64 reads the file's declared contentEncoding and encodes only UTF-8 content. Base64 content passes through, so binary files are never encoded twice, and a file with no declared encoding is still treated as base64 — that preserves AgentEngineSandboxCodeExecutor's current behavior exactly. I did not reuse getEncodedFileContent, whose isBase64Encoded heuristic corrupts plain text that happens to be valid base64 (isBase64Encoded('data') is true). Artifacts written before this fix stay corrupt; there is no migration.

Collision check (575 open PRs on the fork scanned): no PR fixes this call site. #639 edits the same for loop but only moves the artifact-service guard, and #675 renames the file. #410 adds an equivalent helper, toBase64Content, in code_execution_utils.ts for the skill-script path, but leaves code_execution_request_processor.ts untouched, so the bug survives it. I based this on main rather than stacking on #410 because #410 is a 913-line feature PR competing with #517 and #564 for the same feature; stacking would tie this fix to whichever of them lands. Whichever of the two merges second should drop its copy of the helper.

Scope notes:

  • getFileContentAsBase64 is deliberately not exported from common.ts / index.ts. It is an internal helper.
  • I did not add a test for the Artifact service is not initialized. guard. It is pre-existing behavior that Fix: require an artifact service only when a code execution produces output files #639 is actively reworking; a test pinning it here would contradict that PR.
  • npm run ts:check is red on main (281 errors, from @google/adk resolving to core/dist/types while tests also import ../../src). CI does not run it. This change adds 2 errors of that same pre-existing kind, both already present 12 times in the file it touches.

Testing Plan

Please describe the tests that you ran to verify your changes. This is required for all PRs that are not small documentation or typo fixes.

npx vitest run --project unit:core core/test/code_executors/code_execution_utils_test.ts
npx vitest run --project unit:core core/test/agents/processors/code_execution_request_processor_test.ts
npm run build && npm run lint && npm run format:check

All pass. Coverage on core/src/code_executors/code_execution_utils.ts is 100% lines and 100% branches; the changed lines in the processor are each executed by 3 tests.

Proving the tests can fail. Two mutations were run:

  1. Reverted the call site to data: outputFile.content. Two tests failed, one passed:
    • base64-encodes a utf-8 output fileexpected 'hello from script' to be 'aGVsbG8gZnJvbSBzY3JpcHQ='
    • round-trips a utf-8 output file through FileArtifactServiceexpected '\ufffd\ufffde\ufffd\ufffd\ufffd\ufffd…' to be 'hello from script'
    • passes a base64 output file through without encoding it twice still passed, which is the point: the fix does not change binary files.
  2. Flipped the helper comparison to FileContentEncoding.BASE64. Three tests failed:
    • encodes a utf-8 fileexpected '# Notes\n' to be 'IyBOb3Rlcwo='
    • passes a base64 file through unchangedexpected 'aVZCT1J3MEtHZ289' to be 'iVBORw0KGgo='
    • encodes utf-8 text that is itself valid base64expected 'data' to be 'ZGF0YQ=='

Unit Tests:
[x] I have added or updated unit tests for my change.
[x] All unit tests pass locally.
Manual End-to-End (E2E) Tests:
Please provide instructions on how to manually test your changes, including any necessary setup or configuration.

Run an LlmAgent with an UnsafeLocalCodeExecutor and a FileArtifactService rooted at a temp directory. Ask it to write a markdown file. Read the stored payload at <root>/users/<user>/sessions/<session>/artifacts/<name>/versions/0/<name> and confirm it holds the original text. Before this change it holds a few bytes of noise.

The third unit test covers the same path automatically: it drives the real processor into a real FileArtifactService under fs.mkdtemp, with no mocks, and reads the artifact back.

Checklist

[x] I have read the CONTRIBUTING.md document.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] I have added tests that prove my fix is effective or that my feature works.
[x] New and existing unit tests pass locally with my changes.

Amaad Martin added 2 commits August 5, 2026 03:59
Part.inlineData.data must be base64, but File.content is raw UTF-8 text
whenever the file declares contentEncoding UTF8. Read the declared
encoding instead of guessing so callers can build a correct artifact Part.
FileArtifactService and GcsArtifactService base64-decode
Part.inlineData.data before they write it. The processor passed the raw
UTF-8 text of every text output file straight through, so the decode wrote
a few bytes of noise and the artifact was unrecoverable. Binary output
files were already base64 and stay untouched.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant