Reproducing API bugs with property tests

tests/property/ fuzzes the /v3 API in-process against a real Postgres test database. Every test asserts that no response is a 5xx and that no unhandled exception escapes (TestClient re-raises them). Start here when an issue says "I got a 500 when…": the shortest path is usually to get one of these tests to fail on the reported input, then fix the cause.

The harnesses

File	What it drives	Reach for it when
test_api_no_server_errors.py	Schemathesis: every operation, from the app's own OpenAPI schema, in positive and negative mode. Path and body IDs point at seeded resources (seeded_ids) most of the time.	The report is one request.
test_api_inputs.py	Hand-written strategies for what the schema doesn't describe: multipart uploads, the filter DSL, odd JSON in metadata/configuration, store-then-read round trips.	The input is a file, a filter, or a JSON value.
test_api_stateful.py	A RuleBasedStateMachine over workspaces, peers, sessions, messages, conclusions, including use after delete.	The bug needs a history ("after I deleted the session…").
test_api_auth.py	The per-operation fuzzer with auth on and a random token per request (none, forged, expired, admin, workspace/peer/session/named-scope keys across two workspaces), checked against an oracle built from the route policy.	The report involves a scoped key, a 401/403, or data visible to the wrong caller.
test_api_concurrency.py	Batches of requests on colliding names fired at once over httpx's ASGI transport, each on its own DB connection; also checks get-or-create leaves exactly one row.	The bug is intermittent, a spurious 409, or only shows up under load.