MyCarePlanner 2.4.0 - delete-expunge operation error

[mattStorer]

testing the delete-expunge logic in MyCarePlanner 2.4.0, I cleared out the SDS database (so that it was completely empty). I then logged into MyCarePlanner as the OHSU POC rosefhir user. Once logged in, I checked for the presence of resources in the SDS, and found 3 (as expected).

I then went through the process to withdraw data from the SDS, which deleted only the local Patient resource. An error was thrown (and logged) attempting to remove the OHSU Patient resource:

2024-09-17 13:50:20.528 [http-nio-50103-exec-7] INFO  c.u.f.j.d.e.JpaResourceExpungeService [JpaResourceExpungeService.java:243] Deleting resource version Patient/73f255c2-130b-4a80-bcde-18f96daea8a7/_history/1
2024-09-17 13:50:20.539 [http-nio-50103-exec-7] INFO  c.u.f.j.dao.expunge.PartitionRunner [PartitionRunner.java:142] Splitting batch job of 1 entries into chunks of 800
2024-09-17 13:50:20.539 [http-nio-50103-exec-7] INFO  c.u.f.j.dao.expunge.PartitionRunner [PartitionRunner.java:151] Expunging 1 resources
2024-09-17 13:50:20.542 [http-nio-50103-exec-7] INFO  c.u.f.j.d.e.JpaResourceExpungeService [JpaResourceExpungeService.java:243] Deleting resource version Patient/73f255c2-130b-4a80-bcde-18f96daea8a7/_history/2
2024-09-17 13:50:20.556 [http-nio-50103-exec-7] INFO  c.u.f.j.d.e.JpaResourceExpungeService [JpaResourceExpungeService.java:316] Expunging current version of resource Patient/73f255c2-130b-4a80-bcde-18f96daea8a7/_history/2
2024-09-17 13:50:20.573 [http-nio-50103-exec-9] WARN  c.u.f.r.s.i.ExceptionHandlingInterceptor [ExceptionHandlingInterceptor.java:205] Failure during REST processing: ca.uhn.fhir.rest.server.exceptions.ResourceNotFoundException: HAPI-2001: Resource Patient/eFTHaVbQzCEwOEE97maN2MC2jJi-r8nnkhRh.umMUlz03 is not known
2024-09-17 13:50:20.574 [http-nio-50103-exec-9] INFO  fhirtest.access [LoggingInterceptor.java:164] ERROR - POST http://sds-mccecare-dev.ohsu.edu/fhir/Patient/eFTHaVbQzCEwOEE97maN2MC2jJi-r8nnkhRh.umMUlz03/$expunge

At the end of the "withdraw" operation, the OHSU Patient and local Linkage resources remained.

Attempting to log back into the app caused MyCarePlanner to hang with a message that a valid SDS could not be found.

[mattStorer]

1 – DELETE calls are not awaiting response

It appears that the DELETE calls executed by MyCarePlanner aren’t awaiting responses from those operations before kicking off the associated POST $expunge operations.

Consider this screenshot of the network traffic collected during the “withdraw” operation in MyCarePlanner (you can find the source HAR attached to this email). In it, we see the two DELETE operations occurring at 23:37:41.730 and 23:37:41.733, with the second occurring just 3ms after the first. However, the first DELETE call took 288ms to respond, so it’s clear that these operations aren’t waiting for a response from those calls before continuing.

We can see further down that the POST $expunge operations occur at 23:37:41.755 and 23:37:41.757. It’s fine that these occur back-to-back, as $expunge is an asynchronous operation. What’s problematic, though, is that that first DELETE call doesn’t return until (23:37:41.730 + 288 = 23:37:42.018), which is almost a quarter second after the first POST $expunge operation kicks off. Meaning that the POST $expunge is kicking off before the DELETE operation completes.

Fix should be simple enough – just ensure that the DELETE calls block until a response is received from the server.

2 – It looks like X-Partition-Name header is still missing from DELETE call for OHSU Patient record

During the “withdraw” operation, I’m seeing that only the local Patient resource is deleted and expunged, but the OHSU Patient resource isn’t even being marked deleted. It appears that the most likely cause for this is that the DELETE operation isn’t including the “X-Partition-Name” header:

I believe that adding the X-Partition-Name header to DELETE calls pertaining to third-party Patient resources will ensure that those third-party resources are appropriately marked for deletion.

[mattStorer]

this should not be closed. the missing X-Partition-Name header issue persists