home / skills / tursodatabase / turso / differential-fuzzer

differential-fuzzer skill

/.claude/skills/differential-fuzzer

This skill helps you run and analyze the differential fuzzer for Turso, comparing results with SQLite to uncover correctness bugs.

npx playbooks add skill tursodatabase/turso --skill differential-fuzzer

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
4.3 KB
---
name: differential-fuzzer
description: Information about the differential fuzzer tool, how to run it and use it catch bugs in Turso. Always load this skill when running this tool
---

# Differential Fuzzer

Always load [Debugging skill for reference](../debugging/)

The differential fuzzer compares Turso results against SQLite for generated SQL statements to find correctness bugs.

## Location

`testing/differential-oracle/fuzzer/`

## Running the Fuzzer

### Single Run

```bash
# Basic run (100 statements, random seed)
cargo run --bin differential_fuzzer

# With specific seed for reproducibility
cargo run --bin differential_fuzzer -- --seed 12345

# More statements with verbose output
cargo run --bin differential_fuzzer -- -n 1000 --verbose

# Keep database files after run (for debugging)
cargo run --bin differential_fuzzer -- --seed 12345 --keep-files

# All options
cargo run --bin differential_fuzzer -- \
  --seed <SEED>           # Deterministic seed
  -n <NUM>                # Number of statements (default: 100)
  -t <NUM>                # Number of tables (default: 2)
  -c <NUM>                # Columns per table (default: 5)
  --verbose               # Print each SQL statement
  --keep-files            # Persist .db files to disk
```

### Continuous Fuzzing (Loop Mode)

```bash
# Run forever with random seeds
cargo run --bin differential_fuzzer -- loop

# Run 50 iterations
cargo run --bin differential_fuzzer -- loop 50
```

### Docker Runner (CI/Production)

```bash
# Build and run from repo root
docker build -f testing/differential-oracle/fuzzer/docker-runner/Dockerfile -t fuzzer .
docker run -e GITHUB_TOKEN=xxx -e SLACK_WEBHOOK_URL=xxx fuzzer
```

Environment variables for docker-runner:
- `TIME_LIMIT_MINUTES` - Total runtime (default: 1440 = 24h)
- `PER_RUN_TIMEOUT_SECONDS` - Per-run timeout (default: 1200 = 20min)
- `NUM_STATEMENTS` - Statements per run (default: 1000)
- `LOG_TO_STDOUT` - Print fuzzer output (default: false)
- `GITHUB_TOKEN` - For auto-filing issues
- `SLACK_WEBHOOK_URL` - For notifications

## Output Files

All output goes to `simulator-output/` directory:

| File | Description |
|------|-------------|
| `test.sql` | All executed SQL statements. Failed statements prefixed with `-- FAILED:`, errors with `-- ERROR:` |
| `schema.json` | Database schema at end of run (or at failure) |
| `test.db` | Turso database file (only with `--keep-files`) |
| `test-sqlite.db` | SQLite database file (only with `--keep-files`) |

## Reproducing Errors

Always follow these steps

1. **Find the seed** in the error output:
   ```
   INFO: Starting differential_fuzzer with config: SimConfig { seed: 12345, ... }
   ```

2. **Re-run with that seed**:
   ```bash
   cargo run --bin differential_fuzzer -- --seed 12345 --verbose --keep-files
   ```

3. **Check output files**:
   - `simulator-output/test.sql` - Find the failing statement (look for `-- FAILED:`)
   - `simulator-output/schema.json` - Check table structure at failure time

4. **Create a minimal reproducer**
   - Create reproducer in `.sqltest` or in `.rs` always load [Debugging skill for reference](../debugging/)

5. **Compare behavior manually**:
   If needed try to compare the behaviour and produce a report in the end.
   Always write to a tmp file first with Edit tool to test the sql and then pass it to the binaries.
   ```bash
   # Run failing SQL against SQLite
   sqlite3 :memory: < simulator-output/test.sql

   # Run against tursodb CLI
   tursodb :memory: < simulator-output/test.sql
   ```

## Understanding Failures

### Oracle Failure Types

1. **Row set mismatch** - Turso returned different rows than SQLite
2. **Turso errored but SQLite succeeded** - Turso rejected valid SQL
3. **SQLite errored but Turso succeeded** - Turso accepted invalid SQL
4. **Schema mismatch** - Tables/columns differ after DDL

### Warning (non-fatal)

- **Unordered LIMIT mismatch** - LIMIT without ORDER BY may return different valid rows

## Key Source Files

| File | Purpose |
|------|---------|
| `main.rs` | CLI parsing, entry point |
| `runner.rs` | Main simulation loop, executes statements on both DBs |
| `oracle.rs` | Compares Turso vs SQLite results |
| `schema.rs` | Introspects schema from both databases |
| `memory/` | In-memory IO for deterministic simulation |

## Tracing

Set `RUST_LOG` for more detailed output:

```bash
RUST_LOG=debug cargo run --bin differential_fuzzer -- --seed 12345
```

Overview

This skill documents how to run and use the differential fuzzer to find correctness bugs in Turso by comparing its behavior to SQLite. It explains run modes, output files, failure types, and how to reproduce issues for debugging and reporting. Always load the debugging reference before using the tool.

How this skill works

The fuzzer generates SQL statements and executes them against both Turso and SQLite, then compares results and schema to detect mismatches. It records executed SQL, schema snapshots, and database files when requested, and classifies failures (rowset mismatch, error discrepancies, schema divergence). The tool supports single runs, continuous looping, and a Docker runner for CI.

When to use it

  • When validating Turso compatibility with SQLite for randomly generated SQL.
  • When investigating intermittent or hard-to-reproduce query correctness bugs.
  • During CI or long-running fuzz campaigns to discover regressions.
  • When you need reproducible test cases for a failing SQL statement.
  • To capture minimal reproducers for bug reports or upstream investigation.

Best practices

  • Always use a deterministic seed when reproducing issues (--seed) and enable --keep-files to persist DB files.
  • Run with --verbose to print statements and simplify locating the failing SQL in logs.
  • For CI, run the Docker runner with environment variables to control time limits and notifications.
  • When you hit a failure, capture simulator-output/test.sql and schema.json to build a minimal reproducer.
  • Set RUST_LOG=debug for more detailed tracing if a failure needs deeper inspection.

Example use cases

  • Run 1000 generated statements locally to stress-test DDL and DML: cargo run --bin differential_fuzzer -- -n 1000 --verbose
  • Reproduce a reported failure by re-running with the reported seed and keeping files: cargo run --bin differential_fuzzer -- --seed 12345 --keep-files
  • Run continuous fuzzing in loop mode for unattended bug discovery: cargo run --bin differential_fuzzer -- loop 50
  • Integrate into CI using the provided Docker runner and environment variables for time limits and auto-reporting.
  • Compare a failing statement manually by running simulator-output/test.sql against sqlite3 and tursodb to inspect differences.

FAQ

Where are logs and failing SQL stored?

All outputs go to simulator-output/; test.sql contains executed statements and failure markers, schema.json holds the schema snapshot.

How do I reproduce a specific failure?

Find the seed in the run output, then re-run with --seed <SEED> --verbose --keep-files and inspect simulator-output/test.sql and schema.json.