medplum / medplum / 25819900366

92%

main: 92%

push

github

Disable GIN Fastupdate on Appointment, Slot in tests (#9194)

* Disable GIN Fastupdate on Appointment, Slot in tests

While working on scheduling tests that are exercising endpoints using
serializable transactions, I'm seeing CI failing irregularly with "could
not serialize access due to read/write dependencies among transactions".
I'm surprised because the tests shouldn't be conflicting with each other
(they are touching distinct rows), but it seems like Postgres can
sometimes end up locking more than I expected.

@mattlong suggested that FastUpdate could be the culprit - the default
GIN index uses this feature, which can push all the updates to a table
into a single pending list, which could cause this kind of problem. In
this commit we turn off the fastUpdate feature for these tables in the
test environment.

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

* $book: remove leak across transaction retry

When the `bufferSlots` array was defined outside of the transaction
closure, it was not getting cleared if a transaction failed to commit
and retried. This could cause the returned array to include a phantom
Slot that looks persisted but can't be looked up.

Moving this declaration inside `withTransaction` means that each attempt
starts fresh and any instances from previous attempts can be garbage
collected.

This occasionally caused test failures when I was stressing concurrent
scheduling tests.

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

* Test response.body.issue before response.status

When these tests fail, an assertion on the status code is relatively low
utility. Knowing that we expected "201 created" but for "400 bad
request" doesn't help explain why something went wrong.

Adding or moving more specific assertions, such as tests against
`response.body.issue` will hopefully reveal more useful error messages.

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

* Add rationale comment to seed.test index adjustments

Signed-off-by: Noah Silas <noah@m... (continued)

20935 of 23617 branches covered (88.64%)

Branch coverage included in aggregate %.

1 of 1 new or added line in 1 file covered. (100.0%)

34475 of 36613 relevant lines covered (94.16%)

24004.05 hits per line