Function create_sandbox 

pub fn create_sandbox(
    connection: &mut PgConnection,
    parent: &Corpus,
    name: &str,
    selection: &SandboxSelection,
) -> Result<SandboxOutcome, Error>

Carves a sandbox corpus from parent using selection, entirely server-side: it inserts the sandbox corpora row, then a single INSERT INTO tasks (...) SELECT ... FROM tasks ... materializes a TODO task per matched parent entry without ever loading the entries into the application. A 100k-entry carve therefore costs no client RAM and no per-row bind parameters (it sidesteps the 65535-parameter cap a client-side batch insert would hit); the whole carve is one transaction, so it is atomic (no half-built sandbox). Because the matching SELECT over a large parent can take minutes to an hour, this is meant to run as a background job (corpus_sandbox).

A severity-only selection reads tasks directly; a category/what narrowing joins the severity’s log_* table (the table name comes from the fixed TaskStatus::to_table map, so it is never user-controlled; ids/category/what are bound parameters). SELECT DISTINCT collapses a parent task carrying several matching messages to a single carved entry — which also satisfies the tasks UNIQUE(entry, service_id, corpus_id) constraint.

Output-isolation note: the sandbox is its own corpus_id (own tasks, runs, reports). Running a conversion on it would, today, write result archives to the shared <entry-dir>/<service>.zip path it inherits from the parent — so isolating a sandbox’s rerun outputs needs a follow-up (a sink output-path change), tracked in docs/archive/SANDBOX_CORPORA.md + docs/KNOWN_ISSUES.md.