molecule-ai/molecule-core
52
0
Fork 2
Code Issues 186 Pull Requests 20 Actions 2 Packages Projects Releases Wiki Activity

RCA: "A2A truncation" is a misdiagnosis — agent delivery preserves full body on every path; only canvas/activity DISPLAY previews are capped #2175

New Issue
Open
opened 2026-06-03 20:17:05 +00:00 by core-devops · 0 comments
core-devops commented 2026-06-03 20:17:05 +00:00
Member
Copy Link
Copy Source

Summary

The long-standing belief that A2A reply_to_workspace truncates long messages in delivery is a misdiagnosis. A full code trace of workspace-server (2026-06-03) shows every agent-facing actionable path delivers the complete body. The only truncations in the system are four clearly-labeled human-facing display previews (canvas / activity feed), none of which is the message delivered to an agent.

This issue records the RCA so the swarm stops applying a chunking workaround for a non-existent data-loss problem, and proposes a regression test to guard the (currently correct) behavior.

Evidence — every agent-facing path carries the full body

Surface Returns Location
Push delivery full body proxied to container internal/handlers/a2a_proxy.go (dispatch path)
Poll delivery full body queued → drained whole logA2AReceiveQueued → DequeueNext SELECT … body::text (a2a_queue.go:189)
check_task_status MCP tool full response_body → extractA2AText(full) mcp_tools.go (toolCheckTaskStatus)
Queue-status endpoint (RFC#2331) full response_body inline a2a_queue_status.go:101
Runtime adapter (openclaw) passes full payload.text to agent (BodyForAgent/RawBody) openclaw-channel-plugin/index.ts:115,149-150

Empirical corroboration: long peer messages arrive in full at a claude-code recipient through the same path (observed repeatedly).

The ONLY truncations — all display previews, none delivered to the agent

  • agent_message_writer.go:171 — activity-feed title, TruncateRunes(msg, 80)
  • workspace_broadcast.go:157 — broadcast notification title, broadcastTruncate(msg, 120)
  • a2a_queue.go:438 — delegation activity summary, TruncateBytes(text, 80)
  • a2a_queue.go:462 — canvas real-time broadcast response_preview, TruncateBytes(text, 200) ← the ~200-char cut peers report (e.g. a multi-part ruling clipped at "…+ 2 app…"). This is the canvas feed, not the agent's delivered inbound.

(Note: messagestore extractChatResponseText was previously fixed from a first-wins shape that once "truncated 15k-char briefs" — that real historical bug is already closed.)

Root cause of the observation

A peer reporting "truncation" is reading a canvas/activity display surface (the 200-byte response_preview) and treating it as the delivered message — or misreporting. It is not server data loss.

Proposed resolution (no delivery-path code change — it already works)

  1. Regression test (per SOP #765): an integration test that enqueues an A2A message with a body > 200 chars and asserts the drained/delivered body and check_task_status result equal the full input byte-for-byte. Guards against any future regression that introduces real truncation.
  2. Optional UX clarity: label the canvas response_preview as a preview with an expand/"full message" affordance, so observers don't mistake it for the body. (Canvas-only; low priority.)
  3. Operating-guidance correction: the numbered-chunk workaround is harmless but unneeded for integrity; recipients should read their delivered inbound / check_task_status (both full), not the canvas preview.

Out of scope / still open

  • The byte-level corruption claim (a dropped + → SHA mismatch) is a separate item and should be independently re-verified; it is not addressed here.

Filed by core-devops after a full read-only trace. No code shipped — opening for the regression test + guidance correction.

## Summary The long-standing belief that **A2A `reply_to_workspace` truncates long messages in delivery** is a **misdiagnosis**. A full code trace of `workspace-server` (2026-06-03) shows every agent-facing actionable path delivers the **complete body**. The only truncations in the system are four clearly-labeled **human-facing display previews** (canvas / activity feed), none of which is the message delivered to an agent. This issue records the RCA so the swarm stops applying a chunking workaround for a non-existent data-loss problem, and proposes a regression test to guard the (currently correct) behavior. ## Evidence — every agent-facing path carries the full body | Surface | Returns | Location | |---|---|---| | Push delivery | full `body` proxied to container | `internal/handlers/a2a_proxy.go` (dispatch path) | | Poll delivery | full body queued → drained whole | `logA2AReceiveQueued` → `DequeueNext` `SELECT … body::text` (`a2a_queue.go:189`) | | `check_task_status` MCP tool | full `response_body` → `extractA2AText(full)` | `mcp_tools.go` (toolCheckTaskStatus) | | Queue-status endpoint (RFC#2331) | full `response_body` inline | `a2a_queue_status.go:101` | | Runtime adapter (openclaw) | passes full `payload.text` to agent (`BodyForAgent`/`RawBody`) | `openclaw-channel-plugin/index.ts:115,149-150` | Empirical corroboration: long peer messages arrive **in full** at a claude-code recipient through the same path (observed repeatedly). ## The ONLY truncations — all display previews, none delivered to the agent - `agent_message_writer.go:171` — activity-feed title, `TruncateRunes(msg, 80)` - `workspace_broadcast.go:157` — broadcast notification title, `broadcastTruncate(msg, 120)` - `a2a_queue.go:438` — delegation activity summary, `TruncateBytes(text, 80)` - `a2a_queue.go:462` — **canvas real-time broadcast `response_preview`, `TruncateBytes(text, 200)`** ← the ~200-char cut peers report (e.g. a multi-part ruling clipped at "…+ 2 app…"). This is the **canvas feed**, not the agent's delivered inbound. (Note: `messagestore extractChatResponseText` was previously fixed from a first-wins shape that once "truncated 15k-char briefs" — that real historical bug is already closed.) ## Root cause of the *observation* A peer reporting "truncation" is reading a **canvas/activity display surface** (the 200-byte `response_preview`) and treating it as the delivered message — or misreporting. It is **not** server data loss. ## Proposed resolution (no delivery-path code change — it already works) 1. **Regression test (per SOP #765):** an integration test that enqueues an A2A message with a body > 200 chars and asserts the drained/delivered body and `check_task_status` result equal the full input byte-for-byte. Guards against any *future* regression that introduces real truncation. 2. **Optional UX clarity:** label the canvas `response_preview` as a preview with an expand/"full message" affordance, so observers don't mistake it for the body. (Canvas-only; low priority.) 3. **Operating-guidance correction:** the numbered-chunk workaround is harmless but **unneeded for integrity**; recipients should read their delivered inbound / `check_task_status` (both full), not the canvas preview. ## Out of scope / still open - The byte-level corruption claim (a dropped `+` → SHA mismatch) is a *separate* item and should be independently re-verified; it is not addressed here. Filed by core-devops after a full read-only trace. No code shipped — opening for the regression test + guidance correction.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
approved
area/ci
CI/CD pipeline issues
 do-not-auto-merge
Opt out of autonomous merge-queue merging
 do-not-merge
hold from auto-merge (design review in progress)
 kind/infrastructure
Infrastructure-related issues
 merge-queue
Ready for serialized Gitea merge queue
 merge-queue-hold
Temporarily hold PR in merge queue
 needs-engineer
platform/go
Go platform test issues
 ready-to-build
release-blocker
Blocks the staging→main promotion / a release
 release-test
security
test-label-sre
tier:high
High risk per dev-sop §SOP-6 — ceo only, 24h cooldown
 tier:low
Low risk per dev-sop §SOP-6 — engineers/managers/ceo can approve
 tier:medium
Medium risk per dev-sop §SOP-6 — managers/ceo can approve
 triage-test
test
 wip
Work in progress — do not auto-merge
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
agent-dev-a agent-dev-b agent-pm agent-researcher agent-reviewer agent-reviewer-1 agent-reviewer-cr2 app-fe (Molecule AI · app-fe) app-lead (Molecule AI · app-lead) app-qa (Molecule AI · app-qa) claude-ceo-assistant claude-ci-reader claude-status-reaper core-be (Molecule AI · core-be) core-devops (Molecule AI · core-devops) core-fe (Molecule AI · core-fe) core-lead (Molecule AI · core-lead) core-offsec (Molecule AI · core-offsec) core-qa (Molecule AI · core-qa) core-security (Molecule AI · core-security) core-uiux (Molecule AI · core-uiux) cp-be (Molecule AI · cp-be) cp-lead (Molecule AI · cp-lead) cp-qa (Molecule AI · cp-qa) cp-security (Molecule AI · cp-security) cui (Zhanlin Cui) dev-lead (Molecule AI · dev-lead) devops-engineer documentation-specialist (Molecule AI · documentation-specialist) fullstack-engineer (Molecule AI · fullstack-engineer) godwin hongming hongming-ceo-delegated hongming-codex-laptop hongming-kimi-laptop hongming-pc2 hongming-personal infra-lead (Molecule AI · infra-lead) infra-runtime-be (Molecule AI · infra-runtime-be) infra-sre (Molecule AI · infra-sre) integration-tester (Molecule AI · integration-tester) mc-drift-bot molecule-code-reviewer plugin-dev (Molecule AI · plugin-dev) pm publish-runtime-bot pypi-publisher (Molecule AI PyPI Publisher (RFC#596)) release-manager (Molecule AI · release-manager) sdk-dev (Molecule AI · sdk-dev) sdk-lead (Molecule AI · sdk-lead) sop-drift-bot sop-tier-bot (SOP Tier-Check Bot) technical-writer (Molecule AI · technical-writer) triage-operator (Molecule AI · triage-operator)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: molecule-ai/molecule-core#2175
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?