body.id is a pipe slot the engine reuses, not an identifier: rename it or document it at the point of use

[joshuadarron]

body.id looks like an identifier and is not one. It is a pipe slot the engine reuses. Identity throughout is the begin event's continuum seq — that is what the run archive is keyed by, what an answer carries in chat, and what getTrace and traceSlice resolve.

Filed from section 4.3 of the Rocket CRM runtime findings (docRevision 252). Part of the Rocket CRM build tracked in rocketride-ai/rocketride-saas#456.

Mechanism

A field named id on an event body reads as the event's or the run's identity. Keying anything on it produces collisions that look like data corruption, because a later run reuses the slot. Nothing at the point of use says otherwise.

What we do today

Key everything on the begin event's continuum seq, and never touch body.id.

Ask

Rename it, or document it at the point of use — a one-line fix upstream against a multi-hour debugging session for every app that assumes otherwise.

Related

• [docs-drift] Documentation may need updates for pipeline tracing, agentic architecture, and VS Code UI overhaul #131, [docs-drift] Documentation may need updates for pipeline tracing, SDK pipelineTraceLevel option, and VS Code UI overhaul #133 (both closed) — document the apaevt_flow shape {id, op, pipes[], trace} for clients, without saying what id means or warning that it is not an identifier.
• Observability is live-only: no run-history persistence; error/warning arrays capped at 50 #1414 — the adjacent keying complaint: there is no global run id, the key is (project_id, source, startTime), and it is worth a doc callout.

[github-actions]

🤖 Internal: Discord sync marker

Auto-managed by the Discord notification workflow. Stores the linked Discord message ID and forum thread ID. Do not edit or delete.