medplum / medplum / 26603157644

92%

main: 92%

push

github

fix(server): derive bare-id reference prefix from SearchParameter.target (#9325)

* fix(server): derive bare-id reference prefix from SearchParameter.target (closes #9254) (#9256)

* fix(server): derive bare-id reference prefix from SearchParameter.target

Closes #9254

Reference search parameters with a single target resource type now accept
bare ids (the spec-compliant form per FHIR R4 §3.1.1.4.12). Previously, the
bare-id → typed-reference fixup in `buildReferenceSearchFilter` was
hard-coded to the `subject` and `patient` columns, so queries like
`DeviceRequest?encounter=<uuid>` silently returned an empty bundle.

The new behaviour:

  - For literal (non-canonical) reference search parameters whose underlying
    `SearchParameter.target` has exactly one entry, the column impl now
    carries a pre-computed `singleTargetType`. `buildReferenceSearchFilter`
    uses it to prefix bare UUID values with `Type/` before they hit the
    WHERE clause.
  - The existing `subject`/`patient` → `Patient/` fallback is preserved
    verbatim for back-compat on multi-target refs (e.g. `Observation.subject`
    targets [Patient, Group, Device, Location]).
  - Canonical reference params and non-UUID slashless values are left
    untouched to avoid corrupting URNs, canonical URLs, and other
    non-id values.

This mirrors the `searchParam.target?.length === 1` pattern already used
by chained search (`parseChainLink`) in the same file.

Tests cover `DeviceRequest.encounter`, `PractitionerRole.practitioner`,
the array reference column `Encounter.location`, the typed-prefix control,
back-compat for `Observation.subject`, and the non-uuid safety case.

Signed-off-by: Abhishek Gupta <98358742+AbhiMsft@users.noreply.github.com>

* Fix single-target reference derivation for shared search parameters

Shared search parameters like 'encounter' have multiple global targets
(Encounter, EpisodeOfCare), but individual resource types like
DeviceRequest.encounter only target En... (continued)

21654 of 24391 branches covered (88.78%)

Branch coverage included in aggregate %.

28 of 28 new or added lines in 3 files covered. (100.0%)

35555 of 37768 relevant lines covered (94.14%)

23388.7 hits per line