main is red: HTS queries `concepts_search_fts`, a table the schema never creates

[mauripunzueta]

main is currently failing Test Rust deterministically, which blocks every open PR (a PR's CI builds the branch merged with main). Found while merging main into #259; #259 does not touch HTS at all.

The failure

test expand_is_a_filter_with_text_filter_still_nests ... FAILED
thread 'expand_is_a_filter_with_text_filter_still_nests' panicked at crates/hts/tests/value_set_ops.rs:239:5:
assertion `left == right` failed:
  {"resourceType":"OperationOutcome", ... "text":"no such table: concepts_search_fts"}
error: test failed, to rerun pass `-p helios-hts --test value_set_ops`

Root cause: a table that is queried but never created

On origin/main:

• crates/hts/src/backends/sqlite/value_set.rs references concepts_search_fts 13 times (e.g. SELECT EXISTS(SELECT 1 FROM concepts_search_fts …), MIN(bm25(concepts_search_fts)), … MATCH ?1).
• crates/hts/src/backends/sqlite/schema.rs creates exactly four FTS tables, and concepts_search_fts is not among them:
  • implicit_expansion_fts
  • implicit_expansion_word_fts
  • concepts_fts
  • concepts_word_fts
• grep -rn concepts_search_fts crates/hts/src/ finds no CREATE VIRTUAL TABLE for it anywhere.

So the text-filter/search path queries a table that does not exist. Looks like a rename (concepts_fts/concepts_word_fts → concepts_search_fts?) that landed in the query sites but not in the schema.

Why it only surfaced now — a semantic merge conflict

Two changes that were each green in isolation:

1. f6008b29d (HTS IG Publisher $validate-code compatibility) introduced the concepts_search_fts references. Nothing exercised that path, so it stayed latent.
2. 7893ed4f5 / fix(hts): don't default to hierarchical expansion for paged is-a filters (#227) #233 (fix(hts): don't default to hierarchical expansion for paged is-a filters, HTS Terminology Server perf regression on main since v0.2.0 (EX02/EX08 expansion collapse + ~30% uniform drop) #227) added expand_is_a_filter_with_text_filter_still_nests, which sends filter=data and therefore does walk the text-filter path.

Merged together on main, the test hits the missing table on every run.

Fix

Either:

• Add the missing CREATE VIRTUAL TABLE IF NOT EXISTS concepts_search_fts USING fts5(…) to crates/hts/src/backends/sqlite/schema.rs (plus whatever populates it on import), or
• Point the value_set.rs query sites back at the table that does exist (concepts_fts / concepts_word_fts).

Whoever owns the $validate-code change should pick — the two options differ in whether a separate search index was actually intended.

Also worth checking: does the PostgreSQL backend have the same mismatch, and is the corresponding path covered by a test there?

Note on CI noise

main's own CI runs are additionally failing for unrelated infrastructure reasons, which is why this wasn't obvious:

• macOS runner: LLVM ERROR: IO failure on output stream: No space left on device → error: failed to build archive … .rlib (disk full on /Volumes/SN850X-1TB).
• The self-hosted fleet is badly backed up (runs queued 1.5h+), and a MongoDB testcontainer has been failing with TooManyFilesOpen during index builds.

Those are separate from this bug, but they mean main currently has no green baseline at all.

[mauripunzueta]

Precise attribution (git archaeology)

4df65385b  2026-07-10 08:51 -0400   Merge PR #194  (sandhums, HTS IG-Publisher $validate-code)
e5320c5f2  2026-07-14 16:15 -0400   Merge PR #233  (fix/227, HTS expansion collapse)   <-- main went red here

#233 did not introduce the bug — it exposed it.

• feat(hts): IG Publisher $validate-code compatibility #194 planted it (2026-07-10): commit f6008b29d added the concepts_search_fts queries to value_set.rs without adding the table to schema.rs. main stayed green for four days because nothing exercised the text-filter path.
• fix(hts): don't default to hierarchical expansion for paged is-a filters (#227) #233 exposed it (2026-07-14): commit 7893ed4f5 added expand_is_a_filter_with_text_filter_still_nests, which passes filter=data and is the first test to walk that path.

Why #233's CI was green:

$ git merge-base --is-ancestor 4df65385b 7893ed4f5
  (false)

#233's branch tip (dated 2026-07-09) never contained #194's code — the branch was never rebased or re-merged with main after #194 landed on 07-10. So its CI validated the new test against a tree where value_set.rs still queried the FTS table that actually exists.

Two PRs, each green and correct in isolation, broken the moment they coexist. No branch-level CI can catch this, because neither branch is wrong on its own.

Implication for the fix: the owner of #194 should decide whether a separate concepts_search_fts index was genuinely intended (→ add the CREATE VIRTUAL TABLE + populate it on import) or whether the query sites should point back at concepts_fts/concepts_word_fts (→ revert the table name). The test from #233 is correct either way and should stay.

Also worth checking: whether the PostgreSQL HTS backend has the same query/schema mismatch, and whether any test covers that path there.