GrottoCenter / grottocenter-api / 33437846678

91%

Build Type

push

github

Committed by ClemRz

Commit Message

fix(search): make the authorsSort key ordering-correct across scripts

Addresses Paul's review feedback on the author sort key.

- Compute the incremental key from the organization's main name (e.name)
  instead of names[0]. NameService.setNames() resolves e.name from the
  is_main row but leaves e.names unordered, while the full reindex selects
  n.is_main = true, so a document upsert could write a key that a later
  reindex overwrites with a different value
- Replace the '~' sentinel with a leading ordering bucket ('0' + name for
  authored, '1' for authorless). No single sentinel character can work:
  normalization retains Cyrillic, CJK and Latin Supplement letters, and
  Typesense compares sort keys as UTF-8 bytes while JS compares UTF-16
  code units, so any '~'- or U+FFFF-style sentinel is overtaken by some
  legitimate name in at least one of the two orderings. '0' < '1' holds
  in both, whatever script the names use
- Select the alphabetical-first name with an explicit code-point
  comparator. candidates.sort() picks the UTF-16-smallest name, which
  disagrees with UTF-8 byte order for astral-plane characters, so the key
  could hold a name other than the one Typesense ranks first
- Add a regression case with multiple organization names whose main name
  is not the first array element, plus one asserting the incremental key
  equals the full-reindex key for the same organization
- Cover non-Latin names in the ordering tests (Cyrillic, Greek, CJK,
  Hangul, Arabic, Hebrew, Thai, Latin Supplement, astral-plane CJK
  Ext-B, high private use), each asserted under both UTF-16 and UTF-8
  order
- Stop restricting property-test names to the below-'~' alphabet, which
  was masking this bug: the arbitraries now span graphemes and binary
  strings. Add a property pinning byte-order minimality of the selection

The stored key format changes (adam -> 0adam). It is an index-only value
that nothing outside the sort reads, and this PR already requires a full... (continued)

Coverage Stats

5218 of 6267 branches covered (83.26%)

Branch coverage included in aggregate %.

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

23 existing lines in 3 files now uncovered.

9601 of 10702 relevant lines covered (89.71%)

146.82 hits per line