Orqestria Download
← Back to Bug fix

Skill · Version 1.0.0

Minimal API reproductions

Turns a complex backend failure into a small reproducible request and synthetic dataset without exposing real customer information.

api-data-fixture-reproduction

Workflow agents using this skill

See how it helps

When is it useful?

Use when a backend error appears only with certain records or request payloads.

What does it help you do?

  • Reduces requests to the headers and fields necessary to trigger the failure.
  • Builds small synthetic records preserving relevant relationships without copying customer data.
  • Exercises null values, Unicode, numerical boundaries and tied pagination timestamps.

Try asking this

Reproduce skipped orders with identical timestamps using three synthetic records and the smallest failing request. Fetch every page and compare the combined identifiers with the three fixtures. The reproduction should show exactly which order disappears at the page boundary.

Detailed documentation

Read the skill’s original instructions, examples and checks in their authored language.

Details…Show less

API & Data Fixture Reproduction

When to Use

Use when reproducing backend API errors, webhook failures, ORM/SQL query bugs, pagination/filtering anomalies, serialization crashes, or permission edge cases.

Isolating the Minimal Request & Payload

1. Capture & Strip the HTTP Request

When starting from a complex frontend flow, HAR capture, or webhook log:

  • Extract the exact HTTP method, URL path, query string, headers (Content-Type, Accept, Accept-Language, Authorization, Idempotency-Key, custom tenant headers), and request body.
  • Replay the request in an isolated integration test or fetch script.
  • Apply Delta Debugging to the payload and headers: strip optional fields and headers one group at a time until only the exact fields and values required to trigger the bug remain.
2. High-Yield Data Boundary & Edge-Case Triggers

When a bug report says "fails for certain records/users," check these data shapes first:

  • Nullability & Empty Collections: null vs. undefined vs. "" (empty string) vs. [] (empty array); parent records with 0 children vs. 1 child vs. > page_size children; soft-deleted (deleted_at IS NOT NULL) or archived foreign-key relations.
  • Unicode, Encoding & Special Characters: Multi-byte UTF-8 emojis (👨‍👩‍👧‍👦), accented characters (ő, ű, ß), right-to-left text, zero-width spaces (\u200B), SQL wildcard characters (%, _, \), regex metacharacters ([, (, *, +, ?), and quotes/newlines in CSV/JSON strings.
  • Numeric & Financial Boundaries: 0, -0, negative numbers, floating-point precision (0.1 + 0.2), Number.MAX_SAFE_INTEGER (9007199254740991), BigInt serialization, and NaN / Infinity.
  • Pagination & Sorting Ties: Duplicate sort timestamps (created_at ties across page boundaries causing skipped or duplicated rows in LIMIT/OFFSET or cursor pagination).
3. Build Minimal, Anonymized Database Fixtures
  • Never copy raw production database dumps containing customer PII, real emails, passwords, or live API credentials into a test environment.
  • Build a Minimal Synthetic Fixture (1–3 rows with anonymized/fake identifiers) that preserves the exact relational topology and column values responsible for the bug:
    • Example: If a query fails when a user belongs to two organizations where one subscription is canceled and the other is active, seed exactly 1 user + 2 org memberships with those two states.
  • Verify that running the API endpoint or service method against this minimal fixture deterministically reproduces the exact SQL error, wrong aggregation, or 500 exception.

Included files 1

  • SKILL.md