medplum / medplum / 31739184589

92%

main: 92%

push

github

perf(search): fix quadratic query string parsing on duplicate params (#10202)

* perf(search): fix quadratic query string parsing on duplicate params

parseQueryString() paired URLSearchParams.keys() with getAll(). keys() yields
one entry per name/value pair rather than per distinct name, so a query with n
copies of a param iterated n times and rescanned all n pairs on each iteration,
allocating a fresh n-element array and overwriting the same key each time.

This is on the hot path for every FHIR request, since the Express layer defers
query parsing to the router, and batch pays it three times per entry because
BatchProcessor calls router.find() during bucketing, identity resolution, and
execution.

Accumulate in a single pass instead. Output is unchanged: one occurrence stays a
bare string, repeats become an array in document order. Measured on 10k
duplicate params: 720ms -> 2.2ms.

Also:
- parseSearchRequest built its query array with push(...entries), which applies
  each entry as a separate argument and threw RangeError on very large queries.
- Hoist the five fixed special search parameter implementations in
  trySpecialSearchParameter so their FHIRPath expressions parse once at module
  load rather than per matching filter.
- Memoize deriveIdentifierSearchParameter and reuse parsed _include expressions
  via an LRU cache.

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

* feat(fhir-router): reject query strings longer than 70,000 characters

Router.find() now rejects an over-length query string with a 400 before any
parsing work happens. The check is O(1) and runs at the single chokepoint shared
by ordinary requests and batch entries, which call find() directly.

Node caps the request line on real HTTP requests, so the vector this actually
bounds is URLs arriving inside a request body -- batch entry URLs in particular,
which are limited only by maxJsonSize. POST _search is unaffected: it reads the
form-encoded body, which Express already bo... (continued)

24007 of 27182 branches covered (88.32%)

Branch coverage included in aggregate %.

32 of 33 new or added lines in 6 files covered. (96.97%)

42328 of 44777 relevant lines covered (94.53%)

11903.63 hits per line