medplum / medplum / 30318418909

92%

main: 92%

push

github

fix(core): keep UUID values whole when parsing _filter expressions (#9977)

* fix(core): keep UUID values whole when parsing _filter expressions

A `_filter` value that starts with digits followed by "-" was tokenized as a
date literal, so a UUID whose first group is all digits (about 2.3% of random
UUIDs) was truncated at the first letter: `12345678-1234-4123-8123-123456789abc`
became `12345678-1234-4`. The filter parser then silently discarded the leftover
tokens, dropping the rest of the expression.

On the server this made `getSubscriptions` search for the nil UUID project
instead of `_project eq <projectId> or _project pr false`, so no subscription
matched at all -- not the server-scoped one and not the project-scoped one. That
is the intermittent failure in the "Server-scoped subscription fires across
projects when enabled" test: it depended on the randomly generated project
UUID. Reproduced at ~2.5% of iterations before this change, 0 of 800 after.

Only take the dateTime path when the token actually looks like a date, and
otherwise fall back to the string handling already used when digits are followed
by a letter. `dateTimeLiterals` is enabled only by the `_filter` tokenizer.

Signed-off-by: Derrick Farris <derrick@medplum.com>

* fix(core): end unquoted _filter values at token boundaries

Two problems with unquoted values that begin with digits, such as UUIDs:

The fallback that handles them consumed characters up to the next space, so a
value at the end of a nested expression swallowed the closing parenthesis:
`(_id eq 6783655a-6431-4baa-9243-914efcd984da)` failed to parse at all. Consume
up to the first character that cannot be part of a token instead, per the
tokenizer's own `symbolRegex` -- whitespace, ")" and "]" for `_filter`.

`parseFilterParameter` also returned whatever it managed to parse and discarded
the remaining tokens. That is what made the truncated UUID in the previous commit
silently search for the wrong thing rather than re... (continued)

22640 of 25721 branches covered (88.02%)

Branch coverage included in aggregate %.

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

40191 of 42587 relevant lines covered (94.37%)

12255.61 hits per line