medplum / medplum / 25508365634

92%

main: 92%

push

github

Scheduling error path improvements (#9088)

* `badRequest` outcome helper can take multiple expressions

In some situations, we want to report on problems that exist when two
resources conflict. In such a case, we want to emit an OperationOutcome
with an issue that has multiple `expression` attributes.

To that end, our `badRequest()` helper can now take an array of
expression strings as its second argument.

Implementation notes:
- `arrayify` was previously defined in `core.ts`, but `core.ts` imports
  from `outcomes.ts`, and so trying to pull from there could have
  created circular dependencies. Extracting the helper into a new
  `array.ts` lets both files depend on it safely. While there I also
  added test cases.

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

* Improve Scheduling error messaging

As I've been working on these Scheduling APIs, there have been some
ongoing challenges related to giving good feedback. A main issue here is
that the different API shapes mean that things like SchedulingParameters
can come from all kinds of sources.

The main idea in this commit is that we can annotate our in-memory
objects with a special symbol key. The insight here is that Symbol keys
are not enumerable in regular iteration, and so these annotations will
not be serialized to JSON or the database.

One place that this showed immediate potential is in how we access
extension values; when dealing with our complex extension, core's
`getExtension` helper is of limited utility:
- It only finds the first extension with a given URL, but we may have
  many
- It doesn't include path information about where the returned extension
  came from (making creating helpful error messages hard)

I've added a `getExtensions()` helper (note the plural) that can extract
extensions with a specific URL, and annotates the results with the real
index in the extensions array. We can then use that in our scheduling
parameters helpers.

One final difficulty that arose from that: I... (continued)

18678 of 21311 branches covered (87.64%)

Branch coverage included in aggregate %.

146 of 156 new or added lines in 8 files covered. (93.59%)

33861 of 35969 relevant lines covered (94.14%)

13350.53 hits per line