awslabs/fhir-works-on-aws-deployment

[Bug] DELETE behavior

Zambonilli opened this issue · 4 comments

Zambonilli commented

Describe the bug
We're seeing some behavior differences of FWoA and the FHIR r4.0.1 specification around handling the DELETE method. Here are all the issues we're seeing.

  1. DELETE is not idempotent. According to the spec, DELETE calls on already deleted resource instances should return 204, 200 or 202 HTTP status codes. However, FWoA is returning a 404 when calling DELETE for a previously deleted resource instance.
  2. The spec defines calling GET on a deleted resource instance as a HTTP 410 response. FWoA is returning a HTTP 404.
  3. To bring back online previously deleted resource instances, the spec defines making a PUT call for the resource instance and the FHIR server should record a special deleted history entry and create a new version with the payload of the PUT. FWoA returns a 500 Internal Server Error.
  4. Trying to perform any of the above in a bundle transaction results in a 409 failed to lock error but is most likely covering up an internal fatal error.

To Reproduce
idempotent DELETE calls

  1. Create resource instance
  2. DELETE resource instance
  3. DELETE resource instance
  4. assert a 204, 200 or 202 are returned

GET 410

  1. Create resource instance
  2. DELETE resource instance
  3. GET resource instance
  4. assert a 410 status code is returned

Bring back online

  1. Create resource instance
  2. DELETE resource instance
  3. PUT resource instance
  4. GET resource instance
  5. assert 200 is returned
  6. GET resource instance _history
  7. assert version ID 1 is the POST resource instance
  8. assert version ID 2 is a DELETED history entry
  9. assert version ID 3 is the PUT resource instance

Transactions

  1. make sure the above use cases have the same behavior in transactions

Expected behavior
FWoA to match the specification in regards to DELETE. Specifically, we're blocked by not having idempotent behavior on DELETE and the ability to bring back online previously deleted resource instances in transactions. Currently, both paths cause a failure for us to be able to do an atomic update of a patient's data without first querying the deleted state of the resource instances.

Screenshots
v3.3.1-smart

Additional context
Since this is blocking one of our major workloads, we will be creating a public feature branch and PR to shore up these issues. Happy to coordinate with the FWoA team on doing this work so we don't double build or have friction getting PRs merged upstream.

ssvegaraju commented

Hey @Zambonilli , thanks for bringing this to our attention! I'm happy to review the PR whenever it's ready, and I don't believe this will conflict with anything we're working on at the moment.

Zambonilli commented

Created 3 PRs to support the accurate behavior of DELETE in FHIR.

interface: awslabs/fhir-works-on-aws-interface#108
persistence: awslabs/fhir-works-on-aws-persistence-ddb#155 (won't be green until interface is PR is merged and version is bumped)
routing: awslabs/fhir-works-on-aws-routing#178 (won't be green until interface is PR is merged and version is bumped)

Here's the validation we performed.

single delete

  1. create resource
  2. delete resource
  3. assert vread versionid 1 returns 200 w/original resource
  4. assert vread versionId 2 returns 410 w/message indicating a delete op occurred
  5. assert get resource by id is 410

single delete idempotent

  1. create resource
  2. delete resource
  3. delete resource again
  4. assert http 204

recreate single

  1. create resource
  2. delete resource
  3. put resource
  4. assert 201
  5. assert vread version Id 1 returns 200 w/original resource
  6. assert vread version id 2 returns 410
  7. assert vread version id 3 returns 200 w/new resource

transaction delete

  1. create resource
  2. delete resource in tx
  3. assert 200
  4. assert vread version id 1 is 200 w/original resource
  5. assert vread version id 2 is 410

transaction delete idempotent

  1. create resource
  2. delete resource
  3. delete resource in tx
  4. assert 200
  5. assert success for delete in tx
  6. assert vread version id 1 is 200 w/original resource
  7. assert vread version id 2 is 410
  8. assert vread version id 3 is 404

transaction recreate

  1. create resource
  2. delete resource
  3. put resource in tx
  4. assert 200
  5. assert success for resource in tx
  6. assert vread version id 1 is 200 w/original resource
  7. assert vread version id 2 is 410
  8. assert vread version id 3 is 200 w/new resource

batch delete

  1. create resource
  2. delete resource in batch
  3. assert 200
  4. assert vread version id 1 is 200 w/original resource
  5. assert vread version id 2 is 410

batch delete idempotent

  1. create resource
  2. delete resource
  3. delete resource in batch
  4. assert 200
  5. assert success for delete in batch
  6. assert vread version id 1 is 200 w/original resource
  7. assert vread version id 2 is 410
  8. assert vread version id 3 is 404

batch recreate

  1. create resource
  2. delete resource
  3. put resource in batch
  4. assert 200
  5. assert success for resource in batch
  6. assert vread version id 1 is 200 w/original resource
  7. assert vread version id 2 is 410
  8. assert vread version id 3 is 200 w/new resource
Zambonilli commented

Added a PR for subscription reaper to be able to write the explicit delete resource instance document.

#730

nisankep commented

FHIR Works on AWS has been moved to maintenance mode. While in maintenance, we will not add any new features to this solution. All security issues should be reported directly to AWS Security at [aws-security@amazon.com] (mailto:security@amazon.com). If you are new to this solution, we advise you to explore using [HealthLake] (https://aws.amazon.com/healthlake), which is our managed service for building FHIR based transactional and analytics applications. You can get started by contacting your AWS Account team. If you are an existing customer
of FHIR Works on AWS, and have additional questions or need immediate help, please reach out to fwoa-migration-support@amazon.com or contact your AWS Account team.