Skip to content

fix(dataexchange): omit raw data field when IncludeBase64 is true (PILOT-269)#9

Open
matthew-pilot wants to merge 2 commits into
mainfrom
openclaw/pilot-269-20260530-005500
Open

fix(dataexchange): omit raw data field when IncludeBase64 is true (PILOT-269)#9
matthew-pilot wants to merge 2 commits into
mainfrom
openclaw/pilot-269-20260530-005500

Conversation

@matthew-pilot
Copy link
Copy Markdown
Collaborator

What failed

When IncludeBase64=true, saveInboxMessage stored both the raw string(frame.Payload) as data AND its base64 encoding as data_b64, doubling the JSON payload size. For a max 256MiB frame, this produced ~683MiB of JSON per message.

Root cause

service.go:263-272: The data field was unconditionally added to the message map, and data_b64 was then appended on top when IncludeBase64 was enabled.

Fix

Move data into the else branch — when IncludeBase64=true, only data_b64 is populated (canonical lossless representation). When IncludeBase64=false, only data is populated (same as before).

Files changed

  • service.go: +2/-1
  • zz_more_test.go: +20/-6 (tightened assertions: data absent when b64, data_b64 absent when raw)

Verification

go build ./...   ✅
go vet ./...     ✅  
go test ./...    ✅ (0.608s)

Closes PILOT-269

…-269)

The existing test only checked data_b64 presence but never verified
that data was absent when IncludeBase64 is enabled — which is the
2× payload blowup described in the ticket.

This commit will FAIL until the fix in service.go is applied.
…LOT-269)

When IncludeBase64=true, saveInboxMessage stored both the raw
string(frame.Payload) as 'data' AND its base64 encoding as 'data_b64',
effectively doubling the JSON payload size. For a max 256MiB frame,
this produced ~683MiB of JSON (256MiB raw + 341MiB base64 + overhead).

Fix: omit 'data' when 'data_b64' is present — IncludeBase64 operators
get the lossless base64 representation without the duplicate.

Closes PILOT-269
@codecov
Copy link
Copy Markdown

codecov Bot commented May 30, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

@matthew-pilot
Copy link
Copy Markdown
Collaborator Author

🦾 Matthew PR Check — #9 PILOT-269

Status

  • State: OPEN · MERGEABLE ✅
  • CI: 2/2 green (test ✅, codecov/patch ✅)
  • Created: 2026-05-30 01:04 UTC
  • Files: 2 (service.go +2/−1, zz_more_test.go +20/−6)
  • Canary: not-configured

Summary

Narrow fix to service.go: when IncludeBase64 is true, omit the raw data field from the response. Test coverage added in zz_more_test.go. All CI checks pass, mergeable clean.


🤖 matthew-pr-worker · 2026-05-30T01:09 UTC

@matthew-pilot
Copy link
Copy Markdown
Collaborator Author

🦾 Matthew Explains — #9 PILOT-269

What this does

Restructures the inbox message JSON payload so that when IncludeBase64 is enabled, only the data_b64 field is present — the raw data field is omitted. When IncludeBase64 is disabled, only the raw data field is present.

Why

Previously, the raw data field was always included, and when IncludeBase64=true, data_b64 was added alongside it. This caused a 2× payload blowup: every inbox message carried both the raw bytes and the base64-encoded form in the same JSON document. For binary payloads, this doubles the storage/in-transit footprint.

What changed

File +/- What
service.go +2/−1 Move "data" into the else branch — emitted only when IncludeBase64=false
zz_more_test.go +20/−6 Strengthen assertions: verify mutual exclusivity of data and data_b64 per config

Risk

Minimal — this is a response format change in a single function (saveInboxMessage). The test now asserts the invariant both ways (IncludeBase64 true → data absent, false → data_b64 absent). CI is green (test ✅, codecov/patch ✅).

Scope

small — 2 files, +22/−7 lines, logic-only change in the data serialization path.

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