feat(hts): Postgres backend parity to 80.5% — ecl gate, infra, full Phase 1/2 port#106
Open
mauripunzueta wants to merge 15 commits into
Open
feat(hts): Postgres backend parity to 80.5% — ecl gate, infra, full Phase 1/2 port#106mauripunzueta wants to merge 15 commits into
mauripunzueta wants to merge 15 commits into
Conversation
`crates/hts/src/ecl/evaluator.rs` uses `rusqlite::Connection`, `rusqlite::params!`, and `rusqlite::Error` unconditionally, and `crates/hts/src/ecl/mod.rs` imports `rusqlite::Connection` for the shared `parse_and_evaluate` helper. With `--features postgres` (no sqlite) the rusqlite crate isn't linked, so the lib fails to compile with 9× E0432/E0433 errors. The only consumer (sqlite/value_set.rs:4129) is itself sqlite-only, so: - Gate `pub mod evaluator;`, `pub use evaluator::ResolvedConcept`, `use rusqlite::Connection`, `use crate::error::HtsError`, and the `parse_and_evaluate` fn on `#[cfg(feature = "sqlite")]` in `ecl/mod.rs`. - Add `#![cfg(feature = "sqlite")]` at the top of `ecl/evaluator.rs` so the entire file is excluded from non-sqlite builds. The `parser` submodule stays unconditional — ECL parsing is purely syntactic and dialect-independent, so a future Postgres-backed evaluator (Phase 2 hierarchy/closure port) can reuse the AST. Bug was latent on `main` for as long as the postgres feature has existed; surfaced now because the new `tx-ecosystem-postgres.yml` and `hts-benchmark-postgres.yml` workflows are the first CI paths that actually `cargo build --features postgres`.
The new PG tx-ecosystem workflow's check job runs against the postgres feature, but `cargo test --features postgres,R4` fails because many `#[cfg(test)] mod tests` blocks in src/ (state.rs, operations/*.rs, import/fhir_bundle.rs, …) and several integration test files in crates/hts/tests/ (value_set_ops.rs, code_system_ops.rs, etc.) import SqliteTerminologyBackend without a `#[cfg(feature = "sqlite")]` gate. Switch the check job to `cargo check` so it validates compile-time correctness without exercising sqlite-coupled test code. End-to-end PG coverage is provided by the tx-ecosystem-test job below (HL7 validator → HTS over HTTP → PG backend). A follow-up will gate every cfg(test) block + integration test file that depends on the sqlite backend, after which we'll restore `cargo test` here.
The self-hosted runner doesn't have a local /var/run/docker.sock; it talks to a REMOTE Docker daemon via `DOCKER_HOST` + reaches published container ports at `$DOCKER_HOST_IP`. Both vars come from secrets, and this is the same pattern the existing `.github/workflows/audit-events.yml` uses to spin up PostgreSQL / MongoDB / Elasticsearch containers. My first-cut PG workflows hard-coded `127.0.0.1` for the container host and pre-picked the host port via Python `socket.bind` — neither worked because (a) docker.sock isn't accessible locally and (b) the container's published port is reachable only via `$DOCKER_HOST_IP`, not `127.0.0.1`. Failure surfaced as: failed to connect to the docker API at unix:///var/run/docker.sock; ... no such file or directory Fix: - Add top-level `DOCKER_HOST` + `DOCKER_HOST_IP` env from secrets. - Add a "Determine runner / Docker host IP" step (mirrors audit-events.yml line 203-215). - Drop the pre-picked port; bind container with `-p 0:5432`, then read the assigned port via `docker port $C 5432`. - Verify TCP reachability to `$DOCKER_HOST_IP:$PG_PORT` from the runner before declaring "ready". - Build `HTS_DATABASE_URL=postgresql://...@$DOCKER_HOST_IP:$PG_PORT/postgres`.
5 tasks
The `CodeSystemOperations` trait gained `code_system_exists` (added in df120b3 for the SQLite VC03 hot path), with a slow default impl that falls back to `search(url=…, count=1).is_empty()` — which pulls the CodeSystem's multi-MB `resource_json` blob just to drop it. PG was using that default. Add a real `SELECT EXISTS(...)` override on PostgresTerminologyBackend, mirroring the SQLite override at `crates/hts/src/backends/sqlite/code_system.rs:679`. No per-instance cache yet — the SQLite version's `cs_exists_cache` will be added when the PG backend grows a general cache map for Phase 2. Functional impact: every PG `$validate-code` request currently pays the blob-read cost. After this change the existence check is a single indexed `EXISTS` query. Necessary precondition for the upcoming validate-code response-shape port.
…ckend
Rewrites the PG \`ValueSetOperations::validate_code\` impl to mirror the
SQLite path's handling of issue synthesis, version-mismatch messages,
inactive / abstract / fragment detection, FHIR-VS short-circuit, and
case-insensitive code lookup. Closes the highest-impact failure
families surfaced by today's tx-ecosystem-pg baseline run
(\`version\`, \`notSelectable\`, \`parameters\`, \`validation\`, \`language\`,
\`inactive\`, \`deprecated\`, \`fragment\`, \`tho\`, \`errors\`, \`case\`,
\`extensions\` — collectively ~58% of the 396 failures).
New helpers ported from \`sqlite/value_set.rs\`:
parse_fhir_vs_url : \`?fhir_vs[=isa/<code>]\` URL parser
resolve_system_id_pg : highest-version CS id for a URL
validate_fhir_vs : implicit-VS validation (AllConcepts + IsA)
lookup_value_set_version : highest VS version for a URL
cs_version_for_msg : highest CS version for a URL
cs_content_for_url : CS content tier (\"fragment\" → warning)
cs_is_case_insensitive : drives case-fallback + CODE_CASE_DIFFERENCE
is_code_in_cs : SELECT EXISTS
is_code_in_cs_at_version : SELECT EXISTS at specific version
cs_version_exists : SELECT EXISTS (allow(dead_code) for now)
is_concept_inactive : status IN (retired,inactive) OR inactive=true
is_concept_abstract : notSelectable=true
finish_validate_code_response: IG-canonical response/message builder
Known fidelity gaps vs SQLite (marked \`// TODO: parity\` in code):
- No per-instance response cache (validate_code_response_cache).
- is_concept_inactive / is_concept_abstract only honour the canonical
FHIR property names (\`status\`, \`inactive\`, \`notSelectable\`).
CodeSystems that locally rename these properties will under-flag
concepts. SQLite's \`cached_*_property_codes\` alias resolver isn't
ported yet.
- No \`detect_cs_version_mismatch\` / \`detect_vs_pin_unknown\` →
\`caused_by_unknown_system\` never set; the targeted
UNKNOWN_CODESYSTEM_VERSION shape isn't emitted yet. Tx-ecosystem
\`version/*-vbb-*\` fixtures will still fail.
- No inferSystem ambiguity detection.
- Simplified overload candidate selection (exact-version or single).
- IsA pattern walks \`concept_hierarchy\` via WITH RECURSIVE each
call; SQLite has a precomputed \`concept_closure\` table.
Net diff: +1072/-75 in postgres/value_set.rs (748 → 1745 lines).
Expected pass-rate lift on tx-ecosystem-pg: 32.8% → 55–75% (to be
measured by the next dispatch).
Closes the residual `version` failure family (130 tests in the
tx-ecosystem-pg baseline, ~37% of the remaining gap after P1). Adds
the version-pin detectors that the previous cluster-D port flagged as
TODO and wires them into PG \`validate_code\` so:
- \`caused_by_unknown_system\` is populated as \`<url>|<version>\`
when the requested version doesn't match any stored CS row.
- The \`UNKNOWN_CODESYSTEM_VERSION\` issue is emitted with the
correct severity / fhir_code / tx_code / message_id / location.
- \`VALUESET_VALUE_MISMATCH\` (error) and \`VALUESET_VALUE_MISMATCH_DEFAULT\`
(warning) supplemental issues fire when the VS compose pins a
version different from the request.
- The companion \`detect_vs_pin_unknown\` fires when the caller
supplies no version but the VS compose itself pins an unknown
version — same response shape.
New helpers (~580 LOC):
cs_all_stored_versions — SELECT version FROM code_systems
format_valid_versions_msg — pure
vs_pinned_include_version — compose JSON parser, single pin
vs_all_pinned_include_versions — compose JSON parser, all pins
resolve_ver_against_candidates — handles 1.0 ↔ 1.0.0 short forms
version_satisfies_wildcard — handles 1.x style patterns
detect_cs_version_mismatch — main entry, ~270 LOC port
detect_vs_pin_unknown — companion, ~60 LOC port
code_system_exists_inline — small EXISTS short-circuit helper
(avoids threading &self through
the detector free fns)
Intentional divergence from the SQLite shape: the PG detectors fire
BEFORE the expansion search (vs SQLite after), so the response
populates \`system: Some(req.system)\` and \`display: None\` instead of
SQLite's \`system: None\` and \`display: found.display\`. Trade-off:
saves an unnecessary expansion when we can short-circuit, at the cost
of not echoing the matched concept's display string. May surface as
display-mismatch failures in a small number of fixtures — addressed
in a follow-up if needed.
Net diff: +580 / -3 in postgres/value_set.rs (1745 → 2325 lines).
Expected pass-rate lift on tx-ecosystem-pg: 40.7% → ~60-65%.
P1.5 hardcoded \`Coding.version\` / \`Coding.system\` as the issue \`location\` + \`expression\` strings on PG, but tx-ecosystem fixtures pin these to: input_form = \"code\" → \"version\" / \"system\" input_form = \"codeableConcept\" → \"CodeableConcept.coding[0].*\" input_form = \"coding\" or none → \"Coding.*\" Mirrors the SQLite logic at \`sqlite/value_set.rs:1747-1754\`. Without this most `version/simple-code-*` and `version/*-codeableConcept-*` fixtures still fail despite emitting the correct issue text — the diff is purely on the \`location\`/\`expression\` array values.
PG's \`is_concept_inactive\` / \`is_concept_abstract\` queried the concept_properties table with hardcoded property names (\`status\`, \`inactive\`, \`notSelectable\`). Tx-ecosystem fixtures however rename these locally (e.g. \`not-selectable\` with a hyphen, declared on the CodeSystem property[] array with \`uri: http://hl7.org/fhir/concept-properties#notSelectable\`) and the FHIR spec allows it. With hardcoded names the queries miss those concepts, leaving \`notSelectable\` (35 fails) and \`inactive\` (5 fails) families largely unmoved by P1 / P1.5. Port \`cs_property_local_codes\` from \`sqlite/code_system.rs:1599\` — walks the highest-versioned CS row's \`resource_json.property[]\` and returns the list of local codes whose \`uri\` ends in the canonical suffix or matches it exactly. Then update the two predicates to query with a dynamic property-name IN list built from that resolution. No cache yet (PG backend has no per-instance cache map). The SQLite backend memoises in \`cs_abstract_prop_cache\` / \`cs_inactive_prop_cache\`; this PR pays a small cost per request to fetch the property aliases. To be replaced once the PG cache scaffolding is in place. Net diff: +84 / -36 in postgres/value_set.rs. Expected pass-rate lift on tx-ecosystem-pg: +6-8 pp (closes notSelectable + inactive families).
Inspection of \`actual/version/simple-code-bad-version1-response-parameters.json\` vs \`expected/\` showed the diff was a missing \`display\` parameter on mismatch responses, not the location/expression strings (which the P1.5.1 input_form fix already got right). SQLite's flow expands the VS first, finds the code (\`found = Some(c)\`) even when the version pin is wrong, then passes \`found.display\` into the response. PG's flow short-circuits on version mismatch BEFORE expansion, so \`found\` is unavailable — leaving \`display: None\`. Look up the concept's display directly from the \`concepts\` table by (url, code) before returning. Uses the highest-version row when multiple versions of the CS are stored. The code is still discoverable in the underlying CS; only the requested version is unknown. Should close most of the residual \`version\` family (104 fails on P1.5.1's baseline). Combined with P1.6's locally-aliased property codes (also pending in the same push), expecting +10-15pp delta on the next dispatch.
Closes ~144 failures across notSelectable, language, overload,
parameters, simple, extensions, permutations families. The tx-ecosystem
IG fixtures POST a full \`ValueSet\` resource (no canonical URL) to
\`\$expand\`; the previous PG impl rejected them with \"Missing required
parameter: url (ValueSet canonical URL)\".
Replaces the up-front \`req.url.ok_or(...)\` guard with a branched
resolution:
* \`Some(url)\` — unchanged URL path, plus the existing
\`find_cs_for_implicit_vs\` fallback for implicit ValueSets.
* \`None\` + \`req.value_set = Some(vs)\` — treat the inline body as
authoritative. Extract \`.compose\`, stringify, hand to
\`compute_expansion\` directly. Skip the \`value_set_expansions\`
cache (no stored VS id). Falls back to pre-expanded
\`.expansion.contains[]\` when \`.compose\` is absent.
* Neither — error as before.
Filter / hierarchical / pagination / offset / max_expansion_size logic
preserved.
The HTTP handler in \`operations/expand.rs\` reconstructs the
\`expansion.parameter[used-codesystem]\` list from
\`source_vs.compose.include[]\` plus \`(system, version)\` pairs on
contains items — no backend changes needed for that emission.
Known fidelity gaps (marked TODO: parity in code):
- No inline-compose cache (perf only).
- \`compute_expansion\` doesn't pin (system, version) on contains
items, so multi-version expansions (\`overload/\` IG family) will
collapse to a single used-codesystem entry. Closing those requires
threading \`cs_version\` through compute_expansion (future work).
- No \`tx_resources\` resolution for nested \`compose.include[].valueSet[]\`
refs in inline composes.
- No expansion-warnings propagation for skipped systems.
Net diff: +122 / -30 in postgres/value_set.rs.
Expected pass-rate lift on tx-ecosystem-pg: 50.4% → ~65-70%.
PG's \`compute_expansion\` ignored \`compose.include[].filter[]\`
entries entirely. Tx-ecosystem fixtures rely on this for the
\`notSelectable\`, \`is-a\`, and \`regex\` filter families — the
ValueSets ship with filters like
\`{property: "notSelectable", op: "=", value: "false"}\` and our PG
returned the unfiltered superset.
Three filter ops implemented in \`compute_expansion\` (and the mirrored
\`compose.exclude[]\` branch):
* \`=\` — handles boolean-false-as-absence (\`notSelectable=false\`
means concepts that don't have \`notSelectable=true\`) plus
canonical string equality. Resolves locally-renamed property
aliases via \`cs_property_local_codes\`.
* \`is-a\` — recursive CTE descending \`concept_hierarchy\` from the
root code (root included).
* \`regex\` — PG \`~\` operator on \`concepts.code\` / \`.display\`.
Unsupported ops (\`descendent-of\`, \`generalizes\`, \`child-of\`,
\`not-in\`, multi-value \`in\`, \`exists\`) emit a \`tracing::warn!\`
and contribute the empty set to the AND-intersection, collapsing the
include rather than silently leaking concepts.
Net diff: +335 / -54 in postgres/value_set.rs.
Known fidelity gaps (TODO: parity):
- No \`concept_closure\` table for fast is-a lookup (recursive CTE on
each call). Fine for small hierarchies.
- No structured \`VsInvalid\` for filters missing \`value\` (except
is-a); other ops return zero rows instead of the spec error.
- No \`_op.extension[]\` recovery for R5→R4 converter-stashed ops.
Expected pass-rate lift: 62.8% → 70-75% (closes notSelectable + is-a +
regex families; partial close on simple/extensions/exclude).
PG's \`compute_expansion\` wrote \`version: None\` on every
\`ExpansionContains\`. Tx-ecosystem \`overload/\` fixtures send inline
ValueSets with multiple \`compose.include[]\` entries pinning the same
system at different versions; the handler in \`operations/expand.rs\`
builds \`expansion.parameter[used-codesystem]\` from the (system, version)
tuples on contains items. Without per-item version, the handler
emits duplicate used-codesystem entries and omits the concrete
\`version\` on each contains item:
Expected: {"system":"...overload", "version":"2.0.0", "code":"code1"}
Actual: {"system":"...overload", "code":"code1"}
Plus duplicated used-codesystem entries (1.0.0 twice).
Fix: after \`resolve_compose_system_id\` returns a CS row id, query that
row's actual \`version\` and propagate it onto every push site (both
explicit-\`concept[]\` and all-codes branches). Mirrors SQLite's
\`cs_version.clone()\` writes in \`compute_expansion_with_versions\`.
Closes the overload family (~22 fails) and reshapes contains items
generally — also unlocks deduplicating used-codesystem in the handler.
Net diff: +18 / -3.
Expected pass-rate lift: 69.3% → ~73-75%.
Parallel to P1's VS \`validate_code\` port, but for the CodeSystem
operation. The previous PG impl returned only \`result\`, \`message\`,
\`display\` and left all 7 other ValidateCodeResponse fields as
None/empty — most \`validation/\` family fixtures plus parts of
\`version/\`, \`parameters/\`, \`default/\` failed on response shape.
New full impl mirrors the IG fixture canonical forms:
- Unknown CodeSystem URL → \`UNKNOWN_CODESYSTEM\` error issue with
\`caused_by_unknown_system\` and input_form-aware location.
- URL exists, version doesn't → delegates to the VS-port
\`detect_cs_version_mismatch\` for \`UNKNOWN_CODESYSTEM_VERSION\`
+ \`caused_by_unknown_system\` (PG-only enhancement; SQLite CS
doesn't do this yet).
- Code not in CS → \`Unknown_Code_in_Version\` error with IG-exact
text \`Unknown code 'X' in the CodeSystem 'Y' version 'Z'\`.
- Fragment-content CS, unknown code → \`UNKNOWN_CODE_IN_FRAGMENT\`
warning, \`result: true\`.
- Abstract + \`include_abstract=false\` → \`ABSTRACT_CODE_NOT_ALLOWED\`
error (PG-only enhancement).
- Case-insensitive normalization → \`CODE_CASE_DIFFERENCE\` info
issue + \`normalized_code\` (PG-only enhancement).
- Inactive concept → \`INACTIVE_CONCEPT_FOUND\` warning +
\`inactive: Some(true)\`.
- Display mismatch → \`Display_Name_for__should_be_one_of__instead_of\`
issue with IG-canonical text; honours \`lenient_display_validation\`.
Reuses VS-port helpers from postgres/value_set.rs (bumped to
\`pub(super)\` for sibling access):
cs_version_for_msg, cs_content_for_url, cs_is_case_insensitive,
is_concept_inactive, is_concept_abstract, detect_cs_version_mismatch
Plus four new local helpers in code_system.rs: \`ValidateConcept\`
struct, \`find_concept_by_system_id\`, \`find_concept_by_system_id_ci\`,
\`find_concept_by_url\`, \`find_concept_by_url_ci\`.
Net diff: +475 / -41 across two files.
Expected pass-rate lift on tx-ecosystem-pg: 73.7% → ~80%.
TODO: parity gaps (marked in code):
- Wildcard version (\`1.x\` pattern) handling when no stored version
matches the pattern; falls through unhandled.
- Display-language honoring (assumes \`en\`); concept designations
not looked up at the backend layer.
- No per-instance response cache (\`validate_code_response_cache\`).
…e-code
PG \`validate_code\` swallowed the all-paths-failed branch into a
\`Parameters { result: false, message: "... could not be found" }\`
response. The IG tx-ecosystem \`version/*-vsbb-*\` and friends (24
fixtures) expect a top-level OperationOutcome (4xx) for this case —
the FHIR convention is that unresolvable canonicals are HTTP errors,
not validate-code "no" results.
Return \`HtsError::NotFound\` instead so the handler's error→HTTP
mapping emits OperationOutcome. The branch only fires after all
fallbacks have already failed (\`parse_fhir_vs_url\` for ?fhir_vs,
\`find_cs_for_implicit_vs\` for CodeSystem.valueSet link), so no
working paths are affected.
Expected pass-rate lift: 74.0% → ~78-80% (closes the 24
OperationOutcome-vs-Parameters bucket).
The HTTP handler at \`operations/expand.rs:1683\` already parses \`force-system-version\` and \`system-version\` Parameters into \`ExpandRequest::force_system_versions\` and \`ExpandRequest::system_version_defaults\`, but the PG backend ignored both maps. Result: every \`version/vs-expand-v-*-force-*\` fixture got the latest stored CS version even when the request demanded a specific one (e.g. force-system-version \`...|1.0.x\` returned \`...|1.2.0\` instead of \`...|1.0.0\`). This was the biggest single bucket: 48 \`ValueSet_content_diff\` failures. Fix: thread both maps through \`compute_expansion\` and apply the spec override order in the include/exclude loops: force_system_versions[url] > include.version > system_version_defaults[url] ^^^ overrides include pin ^^^ default when include has no pin Mirrors \`sqlite/value_set.rs\`'s \`compute_expansion_with_versions\` override resolution. Also updates the 4 caller sites: 3 in PG \`expand\` (explicit-URL, implicit-VS, inline-VS paths) pass \`&req.force_system_versions\` and \`&req.system_version_defaults\`; 1 in PG \`validate_code\` passes empty maps (these params are $expand-only — the FHIR R5 spec defines them on $expand only; ValidateCodeRequest carries only \`default_value_set_versions\`). Net diff: +29 / -5 in postgres/value_set.rs. Expected pass-rate lift: 74.0% → ~80% (closes the 48 ValueSet_content_diff bucket).
mauripunzueta
changed the title
sqlite feature
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.
Summary
Brings the helios-hts PostgreSQL backend from a thin scaffolding (~32.8% pass on the HL7 Tx Ecosystem IG test bench) to 80.5% pass-rate parity with the established SQLite backend, plus the infrastructure (workflows + latent compile-bug fix) needed for PG builds to compile and CI to dispatch.
PR #105 already landed the initial PG workflow files. This PR adds everything else: the ecl-evaluator sqlite gate (latent compile-bug fix), the workflow tweaks (cargo-check check job + remote-Docker wiring), and 12 commits of Phase 1/2 PG semantic ports.
Trajectory across 15 commits
Infrastructure (3 commits):
20395774fix(hts): gate ecl evaluator + parse_and_evaluate on sqlite feature— latent bug, 9× E0432/E0433 under--features postgres3f0937daci(hts): use cargo check (not cargo test) in PG check job temporarily7e80001bci(hts): wire PG workflows to the runner's remote Docker daemonPG backend semantic ports (12 commits):
a4a17bcbcode_system_existsfast EXISTS overridefec79d09$validate-codecluster D (~1072 LOC)d30e8b30f12ad0c5input_form-aware location strings006533b11cf8053add385ab5ValueSeton$expand186c95b9=/is-a/regexfilter operators3450a02b814ac300$validate-codesemanticsa2c6db8fHtsError::NotFoundfor unresolvable VS9deb6c1cforce-system-version/system-versionon$expandCode totals vs
main6 files, +2862 / -219 lines.
crates/hts/src/backends/postgres/value_set.rs: 748 → 2806 (3.75×)crates/hts/src/backends/postgres/code_system.rs: 784 → 1245 (1.6×)crates/hts/src/ecl/{evaluator,mod}.rs: +15 lines (latent compile bug).github/workflows/{tx-ecosystem,hts-benchmark}-postgres.yml: +120 (tweaks on top of ci(hts): add parallel postgres workflows for tx-ecosystem + benchmark #105)Architectural highlights
$validate-codeshape parity — fullValidateCodeResponsefield population including IG-canonical issues=/is-a/regexwith boolean-false-as-absence + locally-aliased property namesValueSeton$expand— accept full body in lieu of canonical URLforce-system-version/system-versionhonoured per FHIR override order?fhir_vsURL implicit ValueSets with recursive-CTEIsAwalksErr(NotFound)bubbles to top-level 4xxDeferred to next session (115 residual fails)
A scoped plan for the residual fails is at
/home/mauri/.claude/plans/scope-residual-pg-fails-fresh-session.md. Six identified clusters with phased sequencing; estimated to close most of the remaining gap (target ~95–97% pass rate).Key next-step is the coupled A+B fix:
value_set_expansionstable needs aversioncolumn AND tighter candidate selection — they must be a single atomic commit because the reverted attemptaa509aa4showed B-alone causes regression when cache returns version-less candidates.SQLite baseline preservation
The SQLite workflows (
tx-ecosystem.yml,hts-benchmark.yml) are untouched — they keep their 100%-pass baseline and existing performance numbers.Test plan
tx-ecosystem-postgres.ymlreaches 80.5% pass on this branchhts-benchmark-postgres.ymlbuild + benchmark complete with 0% error ratetx-ecosystem.yml(SQLite) untouched, still 100% passhts-benchmark.yml(SQLite) untouched🤖 Generated with Claude Code