Query Replay

Status: Unsupported concept: dashboard manifest only. No canonical entitlement and no supported deployment contract.

:::danger Unsupported legacy concept

This describes a concept that Nexo does not currently implement. It has no canonical entitlement and no supported deployment contract. Do not infer a CRD, Operator reconciliation path, runtime implementation, or support commitment from the configuration and examples below.

:::

Always confirm availability in the release bundle selected for deployment.

At a glance

Property	Value
Pipeline phase	Request + Response
Category	Testing
Canonical minimum tier	No canonical entitlement
Canonical entitlement	No
Supported deployment contract	No
Release status	Unsupported concept: dashboard manifest only. No canonical entitlement and no supported deployment contract.

Release accuracy

• Current documentation: Unsupported concept: dashboard manifest only. No canonical entitlement and no supported deployment contract.

Where any detail below conflicts with the release status above, the release status is authoritative. Field names and examples describe the current dashboard and CRD surface; always confirm behavior against the selected release bundle before relying on it operationally.

Release-aware feature flow. The diagram is explanatory; the release status on this page is authoritative.

Diagram resources: Open the SVG full screen · Download the editable Excalidraw source

Performance impact

:::warning Unverified performance figures

These figures are illustrative only. They are not current benchmarks or service guarantees and have not been verified by the current test suite.

:::

Percentile	Reported figure
P50	<0.3ms
P95	<1ms
P99	<2ms

Note: Recording is async — minimal impact on live traffic

Overview

The Query Replay step captures live MongoDB traffic (queries and responses) and can replay it against a different cluster at configurable speed. This is essential for validating MongoDB version upgrades, schema changes, or hardware migrations.

In compare mode, it simultaneously records and replays, then diffs the responses to detect behavioral differences between the two clusters.

When to use

• Validating MongoDB version upgrades (e.g., 5.0 → 7.0) with real traffic
• Testing schema changes against production query patterns
• Load testing new hardware with realistic workloads
• Reproducing production issues in staging environments

How it works

1. Record mode: captures all (or sampled) request/response pairs to storage
2. Replay mode: reads recordings and sends them to replay_target at configured speed
3. Compare mode: records live traffic, replays in parallel, diffs responses
4. Diff report shows: different result counts, missing documents, new errors
5. Recording includes timestamps for realistic replay pacing

Configuration

“Not specified” means required semantics were not declared for that field.

Field	Type	Default	Required	Description
mode	select	record	Not specified	record, replay, or compare
storage	select	file	Not specified	Where to store recordings
file_path	string	—	Not specified	Storage path for recordings
replay_target	string	—	Not specified	Target cluster for replay
sample_rate	percentage	100	Not specified	Percentage of traffic to record
compare_fields	json	—	Not specified	Response aspects to diff
max_recording_size	string	10GB	Not specified	Max recording size
speed_multiplier	number	1	Not specified	Replay speed (1x = realtime)

Settings reference

No additional settings reference is documented for this component.

Examples

MongoDB upgrade validation

steps:
  - id: builtin:query-replay
    config:
      mode: compare
      storage: s3
      file_path: s3://nexo-recordings/upgrade-test/
      replay_target: mongo-v7-staging:27017
      sample_rate: 100
      speed_multiplier: 1
      compare_fields:
        - result_count
        - document_ids
        - error_code
        - sort_order

Best practices

• Record during peak traffic hours for realistic load testing
• Use compare mode for upgrade validation — replay alone misses behavioral changes
• Set max_recording_size to avoid filling disk during extended recordings
• Replay at 2-10x speed to compress testing timelines

Limitations

• Write operations are replayed but may fail due to unique constraints (expected)
• Sessions and transactions may not replay correctly (ordering dependencies)
• Large binary fields (GridFS) significantly increase recording size
• Compare mode doubles proxy resource usage (processing two response streams)

Security and operational guidance

• This is a legacy dashboard concept, not a canonically entitled Nexo component.
• No supported deployment contract, CRD mapping, Operator reconciliation path, or runtime execution guarantee is published.
• Treat every configuration example and performance number below as historical design material only.

Related steps

• shadow-traffic
• traffic-split
• metrics

Release availability

• Current documentation: Unsupported concept: dashboard manifest only. No canonical entitlement and no supported deployment contract.

See the component catalog for the complete comparison matrix.