Reproduction

When a bundle has sufficient HTTP request context, DebugBundle generates command templates and structured specifications from that captured request. Feasibility describes the available evidence; it does not verify that replay will reproduce the original failure.

Reproduction Artifacts

Each reproduction includes three formats:

cURL

A complete, ready-to-run cURL command:

curl -X POST 'https://api.example.com/checkout' \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json' \
  --data-raw '{"cart_id":"cart_01H...","step":"payment"}'

HTTPie

A complete HTTPie command:

printf '%s' '{"cart_id":"cart_01H...","step":"payment"}' | \
  http POST 'https://api.example.com/checkout' \
  'Content-Type:application/json' \
  'Accept:application/json'

JSON Spec

A structured, machine-readable specification:

{
  "method": "POST",
  "url": "https://api.example.com/checkout",
  "headers": {
    "Content-Type": "application/json",
    "Accept": "application/json"
  },
  "query": {},
  "body": {
    "cart_id": "cart_01H...",
    "step": "payment"
  }
}

The JSON spec is designed for programmatic use — agent tools, test frameworks, and CI pipelines can consume it directly.

Reproduction Confidence

Each reproduction includes a confidence score (0–1) and a reason:

Field	Description
`possible`	`true` if reproduction can be generated; `false` otherwise.
`confidence`	Numeric confidence score (0.0 to 1.0).
`reason`	Why reproduction is (or isn't) possible: `request_context_available`, `insufficient_context`, etc.

Feasibility by Scenario

Different types of bugs have different reproduction feasibility:

Scenario	Feasibility	Notes
Standard HTTP bugs	High	Direct request replay usually reproduces the issue.
Frontend interaction + failing request	Medium-high	Request context is available; browser state may differ.
Background jobs	Unavailable without HTTP evidence	A scheduler or queue failure is not an HTTP replay.
External outage timing	Low-medium	Third-party state can't be replayed.
Race conditions	Low	Timing-dependent; single request replay may not trigger.

An SDK request method of UNKNOWN is a background/placeholder capture, not a usable HTTP request. It returns possible: false with request_method_unavailable. Invalid or credentialed request URLs return request_url_invalid.

When only a relative path is captured and no origin is available, the full API/CLI may retain an example.invalid command template for compatibility, but feasibility is false, confidence is 0.1, and the reason is request_target_unavailable. Supply and verify the real target before using a template. Even a captured HTTP request does not prove that the original application state or failure will recur.

The read-only OpenAI connection returns bounded feasibility guidance and omits stored command strings to preserve its stricter header/body exclusion policy.

What Gets Included

The reproduction engine builds artifacts from the request context captured by the SDK:

Data Source	Used For
`context.request.method`	HTTP method in the command.
`context.request.path`	URL path.
`context.request.query`	Query string parameters.
`context.request.headers`	Request headers (sensitive values are redacted).
`context.request.body`	Request body.
`context.response`	Not included in reproduction (used for bundle context only).

Redaction

Sensitive data is redacted before reproduction artifacts are generated. Authorization headers, cookies, and other sensitive values are replaced with [REDACTED]. This ensures reproduction commands are safe to share in issue trackers, chat, and CI logs.

Header Selection

Replay artifacts keep headers that affect application behavior, content negotiation, CORS origin, authentication state, and request correlation. Browser and transport noise such as Host, forwarded host/proto, Connection, Accept-Encoding, Content-Length, Cache-Control, User-Agent, and Sec-* fetch/client-hint headers is removed so the generated cURL, HTTPie, and JSON spec stay focused on the request an agent can meaningfully replay.

Accessing Reproductions

API

curl https://api.debugbundle.com/v1/incidents/inc_01H.../reproduction \
  -H "Authorization: Bearer dbundle_mem_a1b2c3d4..."

CLI

debugbundle incidents show inc_01H... --reproduction

MCP

get_reproduction(incident_id: "inc_01H...")

When Reproduction Isn't Possible

Temporary storage failures are separate from reproduction feasibility. Hosted processing retries an unreadable or invalid source bundle up to eight times and retains exhausted failures for operator review. Reading an artifact never starts regeneration.

Bundle generation also retries temporary failures reading retained context. Source objects already removed by retention may be omitted; an unavailable storage service is not treated as missing evidence.

Reproduction artifacts require request context. They won't be generated when:

The error occurred outside an HTTP request (background jobs, cron tasks).
The SDK didn't capture request context (configuration, SDK limitations).
The error is in a frontend-only path with no triggering network request.
The event type is log_event, deploy_metadata, or probe_event.

In these cases, reproduction.possible is false and reproduction.reason explains why.

Using Reproductions in CI

The JSON spec format integrates well with test frameworks:

import spec from "./reproduction.json";

test("reproduce incident inc_01H...", async () => {
  const response = await fetch(spec.url, {
    method: spec.method,
    headers: spec.headers,
    body: JSON.stringify(spec.body),
  });

  // Verify the fix: this should no longer return 500
  expect(response.status).not.toBe(500);
});

Next Steps

Incidents — Incident lifecycle and grouping
Bundle Schema — Full bundle JSON structure
MCP Workflows — Agent-driven investigation patterns

Reproduction

On this page