cameleer/cameleer-saas
1
0
Fork 0
Code Issues 22 Pull Requests Actions Packages Projects Releases Wiki Activity

MOAT: Exchange Replay #13

New Issue
Open
opened 2026-03-29 23:24:25 +02:00 by claude · 0 comments
claude commented 2026-03-29 23:24:25 +02:00
Owner
Copy Link

Overview

Re-execute a previously recorded exchange through its original route with an optionally modified start payload. Fully audited — every replay is logged with who triggered it, what was changed, and the full execution result.

Concept

  • User selects a recorded exchange from the trace history
  • Optionally modifies the start payload (headers, body, properties)
  • Platform replays it through the original route on the target agent
  • Full execution trace captured (same as live execution)
  • Diff between original and replay execution available

Relationship to Other MOAT Features

  • Uses Debugger infrastructure — same bidirectional SSE protocol, same agent-side execution mechanics
  • Uses Lineage — replay execution gets full per-processor lineage capture automatically
  • Feeds Correlation — replay traces appear in the correlation graph (tagged as replay)
  • Distinct from Debugger — no breakpoints/stepping, focus is on re-execution with altered input

Protocol

  • Extends existing replay SSE command in cameleer3
  • New fields: sourceExchangeId (original exchange), modifiedPayload, replayId
  • Agent sends back full execution trace tagged with replayId

Audit Requirements (SOC 2 aligned)

  • Immutable audit record per replay: who, when, source exchange, payload diff, execution result
  • Audit log queryable by tenant admins
  • Replay permission gated by RBAC role
  • Production replay requires explicit permission (separate from dev/staging)

Use Cases

  • "What would have happened if the input was X instead of Y?"
  • Reproduce and verify bug fixes without waiting for real traffic
  • Regression testing: replay known-good exchanges after code changes
  • Compliance: prove that a specific payload produces a specific output

Tier Availability

Low Mid High Business
No No Yes Yes

Same tier gating as the Live Route Debugger — dedicated infrastructure only.

## Overview Re-execute a previously recorded exchange through its original route with an optionally modified start payload. Fully audited — every replay is logged with who triggered it, what was changed, and the full execution result. ## Concept - User selects a recorded exchange from the trace history - Optionally modifies the start payload (headers, body, properties) - Platform replays it through the original route on the target agent - Full execution trace captured (same as live execution) - Diff between original and replay execution available ## Relationship to Other MOAT Features - **Uses Debugger infrastructure** — same bidirectional SSE protocol, same agent-side execution mechanics - **Uses Lineage** — replay execution gets full per-processor lineage capture automatically - **Feeds Correlation** — replay traces appear in the correlation graph (tagged as replay) - **Distinct from Debugger** — no breakpoints/stepping, focus is on re-execution with altered input ## Protocol - Extends existing `replay` SSE command in cameleer3 - New fields: `sourceExchangeId` (original exchange), `modifiedPayload`, `replayId` - Agent sends back full execution trace tagged with `replayId` ## Audit Requirements (SOC 2 aligned) - Immutable audit record per replay: who, when, source exchange, payload diff, execution result - Audit log queryable by tenant admins - Replay permission gated by RBAC role - Production replay requires explicit permission (separate from dev/staging) ## Use Cases - "What would have happened if the input was X instead of Y?" - Reproduce and verify bug fixes without waiting for real traffic - Regression testing: replay known-good exchanges after code changes - Compliance: prove that a specific payload produces a specific output ## Tier Availability | Low | Mid | High | Business | |-----|-----|------|----------| | No | No | Yes | Yes | Same tier gating as the Live Route Debugger — dedicated infrastructure only.
claude added the epicobservability labels 2026-03-29 23:24:28 +02:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
auth
Identity, authentication, OIDC, RBAC
 billing
Billing, metering, and Stripe integration
 day-1
Required for initial launch
 epic
Top-level epic grouping related issues
 future
Planned for future release
 infra
Infrastructure, GitOps, K8s orchestration
 licensing
License module and feature gating
 networking
Network isolation, VPN, tenant separation
 observability
Observability integration (cameleer3-server)
 ops
Platform operations and self-monitoring
 phase-1
Phase 1: Foundation + Auth
 phase-2
Phase 2: Tenants + Licensing
 phase-3
Phase 3: Runtime Orchestration + Environments
 phase-4
Phase 4: Observability Pipeline + Inbound Routing
 phase-5
Phase 5: K8s Operational Layer
 phase-6
Phase 6: Billing + Metering
 phase-7
Phase 7: Billing + Metering
 phase-8
Phase 8: Security Hardening + Self-Monitoring
 phase-9
Phase 9: Frontend (React Shell)
 platform
SaaS management platform
 runtime
Camel application runtime
 secrets
Secrets management and vault integration
 security
Security, compliance, SOC 2, audit
 task
Implementation task within a phase
No Label epic observability
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claude
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: cameleer/cameleer-saas#13
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?