Stream: hapi
Topic: delete, 409/200 result codes
René Spronk (Jan 29 2019 at 14:35):
During our FHIR training courses we ask the attendees to run a transaction (a bunch of clinical resources associated with their 'own' patient) on any of the public test servers. We've been doing this for a while now, but we took the precaution of adding a specific tag to those resources. I just wrote script to delete all of these resources (DELETE http verb, obviously), but on HAPI (the dstu4 public server) I quite often get a 409 statuscode. Or: the return code is 200, but the resource hasn't been deleted (the latter currently causes my script to loop). Any suggestions?
René Spronk (Jan 29 2019 at 14:46):
"If the server refuses to delete a resource because of reasons specific to that resource, such as referential integrity, it should return the 409 Conflict status code. " - hmm. Obviously if one attempts to delete a graph of resources there will be dangling references at some point in time. Is HAPI forcing me to use a transaction to delete a full graph (and better don't forget to include anything, for that could cause a dangling link) ?
René Spronk (Jan 29 2019 at 16:20):
Does the HAPI server cache responses to queries? My script executes the sequence REPEAT [ a) query for all resources with a certain meta tag, b) if >0 matches, delete them by means of the fullURLs ]. Problem being that the response to the query remains the same, as if the delete hasn't worked. But if I fetch one of the URLS using Postman, it returns an OperationOutcome to indicate that the resource was deleted..
John Moehrke (Jan 29 2019 at 16:31):
not too unexpected... delete, not just in HAPI or even FHIR, is a highly variable operation. True in databases as well as REST. Add to that the aversion Healthcare has to the concept of delete, given the regulated "medical records retention" requirements. add to that the purge upon intended-use expiration... seems your experience is proving to your students the proper lesson to expect the unexpected when it comes to delete. Policy and technology will get in the way of expectations.
René Spronk (Jan 29 2019 at 17:47):
I'm not complaining about the 409, although HAPI is the only public test server (that we're using in our courses) to check for referential integrity. I'd like to know (according to whatever HAPI rules enforces when it comes to references) how to still delete stuff. Only those that developed HAPI will know the answer, or perhaps its actually documented somewhere.
Caching of search results, and serving those if the same requester sends the same query, that's bugging me a lot more - when deleting stuff, the search result is bogus upon the second query. So if there's caching, what's the timeout - so I can ensure to "wait" before querying again. Only those that developed HAPI will know the answer..
Richard Ettema (Jan 29 2019 at 18:25):
FYI - I found out during this past connectathon that you can control HAPI's search behavior to not send cached results if you send the Cache-Control request header with a value of "no-cache".
René Spronk (Jan 30 2019 at 08:04):
@Richard Ettema Thanks, this does seem to work to deal with the caching issue. I'll still have to deal with the 409s, but that may simply be a matter of reordering the set of resource types I'm deleting, to ensure I hot the ones with 'outbound refs only' before heading for the leaf-nodes in the graph.
Brian Postlethwaite (Jan 30 2019 at 09:39):
Does the OperationOutcome include details of the issues? /with the 409 status)
René Spronk (Jan 30 2019 at 10:10):
I haven't actually checked OperationOutcome.. reordering the sequence of deletes has solved the issue. I was thinking of writing a recursive procedure to delete resources in the correct order, but that would need a "find all resources (of any kind) that have a reference to the current resource" kind of functionality, and there's no easy way of doing that in FHIR.
Brian Postlethwaite (Jan 30 2019 at 11:09):
I thought that the OpOutcome along with the 409 might have included those details to help your job - it could also have been empty, but at least worth a look. Glad you've got it sorted now anyway.
René Spronk (Jan 31 2019 at 10:58):
OperationOutcomes does note (in text) that another resource still references it, and also shows the name of the reference (e.g. Patient.managingOrganisation).
Brian Postlethwaite (Feb 02 2019 at 11:20):
I guess that's at least something ;)
Good to know.
Last updated: Apr 12 2022 at 19:14 UTC
