Replace the in-memory job controller (InMemoryController in crates/rest/src/export/) behind the async $viewdefinition-export / $sqlquery-export operations with database-backed job state, following the pattern already used by Bulk Data $export (whose job store shares the primary database).
Problem
Today, job status, tenant ownership, progress, and cancellation state live only in process memory:
- A server restart invalidates every in-flight and completed status URL, undermining the spec's 24-hour manifest validity.
- A second instance cannot see jobs submitted to the first.
⚠️ Until this change is complete, deployments serving SQL-on-FHIR async operations must not be clustered — run a single HFS instance for these endpoints, or pin them to one instance behind the load balancer. Synchronous $viewdefinition-run / $sqlquery-run and Bulk Data $export are unaffected.
Scope
- Move SoF export job state (status, tenant ownership, progress, cancellation) into database-backed storage
- Follow the existing Bulk Data
$export job store pattern
- Preserve 24-hour manifest validity across restarts and across instances
Tracked on the ROADMAP under Next → FHIR Server Capabilities.
Replace the in-memory job controller (
InMemoryControllerincrates/rest/src/export/) behind the async$viewdefinition-export/$sqlquery-exportoperations with database-backed job state, following the pattern already used by Bulk Data$export(whose job store shares the primary database).Problem
Today, job status, tenant ownership, progress, and cancellation state live only in process memory:
$viewdefinition-run/$sqlquery-runand Bulk Data$exportare unaffected.Scope
$exportjob store patternTracked on the ROADMAP under Next → FHIR Server Capabilities.