• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

medplum / medplum / 25819900366 / 1
92%
main: 92%

Build:
Build:
LAST BUILD BRANCH: testing/agent-vitest-migration
DEFAULT BRANCH: main
Ran 13 May 2026 07:08PM UTC
Files 898
Run time 50s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

13 May 2026 06:55PM UTC coverage: 92.238% (+0.001%) from 92.237%
25819900366.1

push

github

web-flow
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)

21785 of 24599 branches covered (88.56%)

Branch coverage included in aggregate %.

44183 of 46920 relevant lines covered (94.17%)

18731.03 hits per line

Source Files on job 25819900366.1
  • Tree
  • List 898
  • Changed 85
  • Source Changed 2
  • Coverage Changed 84
Coverage ∆ File Lines Relevant Covered Missed Hits/Line Branch Hits Branch Misses
  • Back to Build 25819900366
  • 5621e1df on github
  • Prev Job for on gh-readonly-queue/main/pr-9194-b34c356b704f7ab50d29d9333a1dd5aad0ec7313 (#25818434881.1)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc