The spec is moving the two async export operations ($viewdefinition-export and $sqlquery-export) onto the simplified FHIR Asynchronous Interaction Request Pattern (see HL7/sql-on-fhir PR HL7/sql-on-fhir#369). The shared test suite doesn't currently cover HTTP operation flows, so this issue captures the behaviour that conformance tests should exercise once a harness for that exists.
The flow to test:
- Kick-off with
Prefer: respond-async returns 202 Accepted with a Content-Location header carrying the status URL. Invalid requests are rejected synchronously with 4xx/5xx and an OperationOutcome, never deferred to the status URL.
- While the job is running,
GET on the status URL returns 202 Accepted, with Retry-After recommended and X-Progress optional.
- Once the job has finished - successfully or not - the status poll returns
303 See Other with a Location header carrying the result URL and an empty body. The status endpoint never communicates job outcome.
GET on the result URL returns 200 OK with the manifest Parameters resource for a successful export, or the error status code (e.g. 500) with an OperationOutcome for a failed one. Repeated fetches within the validity window return the same outcome.- The result URL and the
output.location download URLs stay valid for at least 24 hours; an Expires header is optional.
DELETE on the status URL returns 202 Accepted (optional OperationOutcome body), and subsequent polls of the status URL return 404 Not Found.- Excessive polling may be answered with
429 Too Many Requests; clients are expected to back off exponentially, guided by Retry-After.
Happy to talk through any of this - the wire-level details are all on the operation pages in the PR linked above.
The spec is moving the two async export operations (
$viewdefinition-exportand$sqlquery-export) onto the simplified FHIR Asynchronous Interaction Request Pattern (see HL7/sql-on-fhir PR HL7/sql-on-fhir#369). The shared test suite doesn't currently cover HTTP operation flows, so this issue captures the behaviour that conformance tests should exercise once a harness for that exists.The flow to test:
Prefer: respond-asyncreturns202 Acceptedwith aContent-Locationheader carrying the status URL. Invalid requests are rejected synchronously with4xx/5xxand anOperationOutcome, never deferred to the status URL.GETon the status URL returns202 Accepted, withRetry-Afterrecommended andX-Progressoptional.303 See Otherwith aLocationheader carrying the result URL and an empty body. The status endpoint never communicates job outcome.GETon the result URL returns200 OKwith the manifestParametersresource for a successful export, or the error status code (e.g.500) with anOperationOutcomefor a failed one. Repeated fetches within the validity window return the same outcome.output.locationdownload URLs stay valid for at least 24 hours; anExpiresheader is optional.DELETEon the status URL returns202 Accepted(optionalOperationOutcomebody), and subsequent polls of the status URL return404 Not Found.429 Too Many Requests; clients are expected to back off exponentially, guided byRetry-After.Happy to talk through any of this - the wire-level details are all on the operation pages in the PR linked above.