Stream: bulk data
Topic: RESTful error status codes for the polling endpoint
Lee Surprenant (Feb 20 2020 at 20:31):
Which HTTP status codes are the various implementations returning in the case of "total failure" (https://hl7.org/fhir/uv/bulkdata/export/index.html#response---error-status-1)?
Lee Surprenant (Feb 20 2020 at 20:31):
For example, you accepted the export request, but then (perhaps due to misconfiguration, a disk error, etc.) were unable to write any files anywhere.
Lee Surprenant (Feb 20 2020 at 20:32):
Is there a code i could use that would clearly distinguish "the job failed" vs the status check failed?
Lee Surprenant (Feb 20 2020 at 20:33):
IMHO the export-status endpoint should always return 200 OK if the job is complete and the status check was successful (irregardless of whether the job was successful or not), but unfortunately the current bulk export spec doesn't seem to agree with me...
Lee Surprenant (Feb 20 2020 at 20:35):
I really wish the Complete Status response gave me a reasonable way to report a total failure that doesn't involve pointing at some URL somewhere else
Josh Mandel (Feb 21 2020 at 16:41):
IMHO the export-status endpoint should always return 200 OK if the job is complete and the status check was successful (irregardless of whether the job was successful or not), but unfortunately the current bulk export spec doesn't seem to agree with me...
This is a fair point! Something we can track as we work toward v2, if you wan to submit an issue on this.
Josh Mandel (Feb 21 2020 at 16:42):
I really wish the Complete Status response gave me a reasonable way to report a total failure that doesn't involve pointing at some URL somewhere else
You mean, like a way to embed a single, summary-level OperationOutcome in the status response body?
Lee Surprenant (Feb 21 2020 at 17:08):
Yep. For now I could put it in the extension field, but I'm not sure anyone would check that (and "total failure" is kind of important for them to understand) :-)
Lee Surprenant (Feb 21 2020 at 17:10):
Something we can track as we work toward v2, if you wan to submit an issue on this.
prefer hl7 jira or a github issue at https://github.com/hl7/bulk-data/issues ?
Josh Mandel (Feb 21 2020 at 17:17):
Official answer is Jira, but if you submit on GitHub we'll take care of keeping track...
Lee Surprenant (Feb 21 2020 at 17:18):
Ok, I'm fine with either. Will go the official route I guess, although its making me choose 0.1 for the version (even though 1.0.0 is published)
Josh Mandel (Feb 21 2020 at 17:19):
The perpetual problem with trying to organize data inputs ! @Lloyd McKenzie do you know how to include the correct version in the list?
Lee Surprenant (Feb 21 2020 at 17:27):
https://jira.hl7.org/browse/FHIR-26367
Lee Surprenant (Feb 21 2020 at 17:28):
aside: how do i get that nice J#26367 -style link to happen? do you need to create the link the old-fashioned way? Update: oh, like that, ha
Lloyd McKenzie (Feb 21 2020 at 17:41):
It's actually best practice to use FHIR#26367 rather than J#26367 because in a little while we're going to start to see v2 and CDA projects as well.
Lloyd McKenzie (Feb 21 2020 at 17:41):
@Josh Mandel to define the versions, artifacts, etc. follow the guidance here: https://confluence.hl7.org/display/HL7/Configuring+Specification+Feedback. The guidance is brand new and unreviewed so corrections/feedback is welcome.
Josh Mandel (Feb 21 2020 at 18:20):
Thanks -- @Ricky Sahu it'd be great to try configuring so Bulk Data versions are aligned.
Josh Mandel (Feb 21 2020 at 18:22):
Quick feedback @Lloyd McKenzie : For properties like specification.version, how do I learn if it's okay to repeat them? https://confluence.hl7.org/display/HL7/Configuring+Specification+Feedback doesn't say.
Lloyd McKenzie (Feb 21 2020 at 18:45):
The schema does, but I can add that to the documentation too
Josh Mandel (Feb 21 2020 at 18:47):
Schema? ;-)
Lloyd McKenzie (Feb 21 2020 at 18:49):
:P
Josh Mandel (Feb 21 2020 at 23:51):
Also @Lloyd McKenzie the order of properties in the docs should match the schema. Better still, we should use JSON and not worry about the order of properies. Even moving defaultVersion down where I think the schema says it's supposed to go, I'm failing with:
[schemavalidate] /home/runner/work/JIRA-Spec-Artifacts/JIRA-Spec-Artifacts/xml/FHIR-bulkdata.xml:13:33: cvc-complex-type.2.4.a: Invalid content was found starting with element 'defaultVersion'. One of '{page}' is expected.
(For now, you can see where I commednted this line out in the PR.)
Lloyd McKenzie (Feb 22 2020 at 18:05):
Ant knows how to validate xml schema but not JSON schema and I can manipulate xml with xslt when generating the Jira files, and when producing sample spec definitions from IGs. So that's a more complex shift than it sounds. Default Version should be an attribute. I'll improve the documentation to make attributes vs. Elements clear.
Josh Mandel (Feb 22 2020 at 20:22):
Thanks! (Yeah, right now there's no attribute-vs-element distinction.)
Lloyd McKenzie (Feb 23 2020 at 17:41):
@Josh Mandel Documentation updated and pull request approved. (I note that you didn't deprecate version 0.1 - did you want to?)
Josh Mandel (Feb 24 2020 at 15:50):
Thanks! And I do want to -- thanks for the pointer re: deprecation.
Josh Mandel (Feb 24 2020 at 15:52):
Will add a new PR.
Last updated: Apr 12 2022 at 19:14 UTC
