Stream: inferno
Topic: BDE-10: Test Details: Bulk Data Server returns "202 Accepted
Michelle Vondercrone (Jan 24 2022 at 16:59):
Inferno test is for Delete Request, but Inferno is making GET request to the /$export, whereas, it should have sent a DELETE request to the content-location URL.
I have never opened a ticket to Inferno before, but there needs to be one opened for this. If someone could walk me through how to do that, I'd appreciate it.
Yunwei Wang (Jan 24 2022 at 17:56):
BDE-10 has two queries. The first is, as you mentioned, a GET to the $export endpoint to generate a new export request. The 2nd is a DELETE request to cancel the just created export request. The reason is that Inferno uses the export request created in BED-06 in the next test sequence "Group Compartment Export Validation Tests". Depending on server's business logic, the server MAY remove exported files with the DELETE request. To avoid that from happening, BED-10 creates and then deletes a separated $export request.
Yunwei Wang (Jan 24 2022 at 18:36):
BTW, @Michelle Vondercrone here is how to open an Inferno ticket:
If you are using web client, no matter it is inferno.healthit.gov or locally installed docker image, you could find the "Issues" link at the bottom of page, like
image.png
That "Issues" link redirects to either https://github.com/onc-healthit/inferno-program/issues (for Inferno Program edition) or https://github.com/onc-healthit/inferno/issues (for Inferno Community edition).
Then you can create a new issue for Inferno following the template.
Michelle Vondercrone (Jan 24 2022 at 22:03):
Problem wit BDE-10 for me is that we have coded condition where if the request is the same (same _type, same _since, same group id) and has not been previously deleted, we will return a http 409 for duplicate request. :(
Michelle Vondercrone (Jan 26 2022 at 15:43):
@Yunwei Wang - any suggestions related to my previous comment? Should I open a ticket to Inferno requesting changes for this test?
Yunwei Wang (Jan 26 2022 at 16:27):
@Michelle Vondercrone sorry that I missed your reply. This is an interesting use case. Think about this work flow:
- Client creates an $export request,
- Server generates nsjson files,
- Client downloads those files (optional),
- Client create another $export request (with the same parameters: _type, _since, group id)
Does your server reject the 2nd $export request in this work flow?
Michelle Vondercrone (Jan 26 2022 at 16:43):
@Yunwei Wang
Yes, for #4 above, we would reject with a http 409 Duplicate Request. We supply an Operation Outcome with this information:
- Severity = Error
- Code = Duplicate
- Details/Text = Existing request <92d73dec-b9e8-436d-bc10-24deaa3287b8> from population application has the same parameter values. If the same export request is desired to pick up the latest data, a Delete Request can be performed against the existing request using URL: <[http://ASCAPPNV8560.usmlvv1d0a.smshsc.net/Patientapi/fhir-api/bulk-api/r4/request/92d73dec-b9e8-436d-bc10-24deaa3287b8]>.
- Diagnostics = Duplicate request received from population application using the same values in _since parameter and in _type parameter. Reference id for support: [d948ebfa-6c3d-4a51-8d8b-a57685faaf26].
If a DELETE request is sent (or a cancel request from a Request Manager UI we've created), then we set a Purge status = requested and then a new group export with those same values would be accepted without failure.
Yunwei Wang (Jan 26 2022 at 16:57):
This is interesting because after server generates ndjson files, the $export request is in complete status as defined here. Why does a server require client to send DELETE to a completed $export request? Assume a client runs daily export job, the client has to DELETE prior day's export first in order to run current day's export. Is that correct?
Michele Mottini (Jan 26 2022 at 18:36):
Presumably the current day export would have a different _since from the last day one
Michele Mottini (Jan 26 2022 at 18:37):
But still it seems fine for clients to request twice the same exact export - maybe the files got corrupted somehow, or maybe it just want all the new data and also the one it already got. I don't think a server should reject that
Yunwei Wang (Jan 26 2022 at 18:49):
Yes. I think it is reasonable to limit a client having one "processing" request at any time point but a server should allow a client to create new request after previous one completed.
Last updated: Apr 12 2022 at 19:14 UTC
