Dry runs

[Scr4tch587]

What

Add ?dry-run=true to POST /build. Runs the full build (including all dependencies) against an in-memory store, writes nothing to the DB, and returns the produced rows so builder logic can be validated.

How

• New Store ABC over the four build-path data ops
• PostgresStore — thin shell over core.db.datasets (real builds)
• MemoryStore — in-process dict backend (dry runs)
• store threaded through run_build → execute_job → _fetch_dep_data
• worker no longer calls core.db.datasets directly
• build_dataset(dry_run=...) is the single boundary that selects the store
• MemoryStore starts empty, so a dry run rebuilds the whole graph in isolation
• no build lock (nullcontext) — a dry run can't corrupt real data
• no cleanup — store is GC'd when the request ends
• json round-trip on insert mirrors Postgres Jsonb serialization

Response

• real build: {"status": "ok"}
• dry run: {dataset_name, dataset_version, dry_run, rows}

Why

• validate builder output without touching real data
• same build logic runs for real and dry runs — store is the only difference

Testing

• MemoryStore unit suite + PostgresStore/MemoryStore read-method parity
• dry-run integration: DB untouched, builders actually run, chain + lookback graphs
• full suite green against real Docker Postgres