fix(search): populate FTS for NSID-keyed collections#59
Merged
tompscanlan merged 2 commits intoJun 15, 2026
Conversation
shortNameForNsid returns undefined when a collection is keyed directly by its NSID, so the FTS-sync and existing-record lookup paths skipped those collections, leaving full-text search empty and replay/update detection broken. Add a resolveCollectionKey helper that returns the storage key (alias or NSID) and use it at all three record paths.
A collection keyed directly by its NSID (no short alias, omitted `collection` field) was only handled at the records/FTS layer via `resolveCollectionKey`. The real ingestion entry points still skipped it: `getCollectionNsids`/`getDiscoverableNsids`/`getDependentNsids` produced undefined NSIDs (Jetstream never subscribed, backfill never ran), `shortNameForNsid` returned undefined (notify rejected the URI as "collection not tracked"), and `validateConfig` rejected the config. Make `CollectionConfig.collection` optional, normalize an omitted value to the map key in `resolveConfig`, accept NSID-keyed entries in `validateConfig`, and resolve the NSID as `collection ?? key` at every collection-list and lookup site so behavior is correct on both raw and resolved configs. Add config-layer regression tests and an end-to-end notify->ingest test for an NSID-keyed collection.
tompscanlan
force-pushed
the
fix/fts-nsid-keyed-collections
branch
from
584cb94 to
deac05c
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When a collection is keyed directly by its NSID (no short alias /
collectionfield),shortNameForNsid(config, nsid)returnsundefined. Two of the three record paths usedshortNameForNsiddirectly:buildFtsStatementsskipped FTS sync, so full-text search stayed empty for NSID-keyed collections.lookupExistingRecordsskipped them, so replay/update detection (and FTS reconciliation) was broken.Only the records-insert path carried the NSID fallback, so rows landed in the records table but never in FTS. The repo's own
search.test.tsuses NSID-keyed configs and was failing 7/12 on a clean checkout.Fix
Add a small
resolveCollectionKey(config, nsid)helper incontrail-basethat returns the storage key (short alias, or the NSID itself when keyed directly), ornullwhen unknown. Use it at all three record paths so they resolve collections consistently. This also de-duplicates the fallback expression the insert path was inlining.Tests
resolve-collection-key.test.tsunit-tests the helper (alias-keyed, NSID-keyed, unknown).search.test.ts(12 tests) now passes; it was the failing regression test.Changeset included (patch:
contrail-base,contrail-appview).