medplum / medplum / 25902758472

92%

main: 92%

push

github

Add $cancel Scheduling operation (#9157)

* Add $cancel Scheduling operation

Adds the `/Appointment/$cancel` FHIR operation, which cancels a booked
or pending appointment by setting its status to cancelled and deleting
all referenced Slot resources in a serializable transaction.

Resolves: #7691
Signed-off-by: Noah Silas <noah@medplum.com>

* Convert $cancel to instance level operation

In review @ThatOneBro pointed out that this looks like it is best
expressed as an instance-level operation. Let's switch over!

Signed-off-by: Noah Silas <noah@medplum.com>

* PR Feedback: Include current state in error message

Signed-off-by: Noah Silas <noah@medplum.com>

* Fixup $cancel docs for instance-level operation

Signed-off-by: Noah Silas <noah@medplum.com>

* Distinguish book/cancel test dates

These tests are sometimes failing due to transaction serialization
failures in CI; example:
https://github.com/medplum/medplum/actions/runs/25828720885/job/75888642509?pr=9157

It seems to be the case that the `$book` and `$cancel` tests are run
simultaneously due to their alphabetical proximity, and they both are
causing updates to the Slot and Appointment tables.

One thought is that there are search parameters on fields like
Slot.start that generate indexes on the data in these fields. Because
these tests were initialized by copy/paste, they share some dates. This
makes it quite likely that they are touching the same entries in those
indexes.

The idea here is that we can potentially prevent that collision by
making the start times in one test case distinct from the other.

Signed-off-by: Noah Silas <noah@medplum.com>

* Increase transactionAttempts in scheduling tests

We're still seeing some issues in CI where $cancel and $book seem to be
colliding. Let's try turning up the transactionAttempts to see if we can
make this more resilient.

Signed-off-by: Noah Silas <noah@medplum.com>

* Use `makeOperationDefinition` helper

Following the pattern set in #9205.

Sig... (continued)

21080 of 23775 branches covered (88.66%)

Branch coverage included in aggregate %.

17 of 17 new or added lines in 2 files covered. (100.0%)

34727 of 36872 relevant lines covered (94.18%)

23859.11 hits per line