Summary
Incremental Phase 3b loads the base V6 store for class attribution (fluree-db-indexer/src/build/incremental.rs, ~line 1897). On a load_from_root_v6 failure it currently only warn!s and continues with store_opt = None — it does not IncrementalAbort. With store = None, every base ClassStatEntry is dropped (the subject sid64 resolves to 0 in the seed loop, ~line 2604), so novelty-only (wrong) class stats get published into the root.
This became a HEAD-correctness risk once the lex_sorted_string_ids provenance gate was removed (#1266): count_plan_exec::try_type_star_pred_fold now runs on any base index, so it would serve a wrong COUNT(*) at HEAD from those stale class stats.
Severity
Narrow — requires a transient base-store load failure during an incremental build that includes rdf:type — but it is a correctness bug (silently wrong query result), and it precedes adding more class-stat fold paths (e.g. the bound-class fold), which would inherit the same exposure.
Fix
Make the base-store load failure return Err(IncrementalAbort(...)) → caller falls back to a full rebuild (which recomputes class + ref stats from scratch), mirroring the oversized-re-type gate (incremental.rs ~line 2086).
Minor sibling (perf-only, not correctness)
An all-quiet increment (no class deltas and no subject-property records) fails the Phase 3b gate (~line 1840); id_hook finalize sets classes: None with no carry-forward else-branch, so class stats are wiped → the fold declines and falls back to a scan (correct, just unaccelerated until the next rebuild). Worth a carry-forward of the prior class stats when there are no deltas.
Summary
Incremental Phase 3b loads the base V6 store for class attribution (
fluree-db-indexer/src/build/incremental.rs, ~line 1897). On aload_from_root_v6failure it currently onlywarn!s and continues withstore_opt = None— it does notIncrementalAbort. Withstore = None, every baseClassStatEntryis dropped (the subject sid64 resolves to 0 in the seed loop, ~line 2604), so novelty-only (wrong) class stats get published into the root.This became a HEAD-correctness risk once the
lex_sorted_string_idsprovenance gate was removed (#1266):count_plan_exec::try_type_star_pred_foldnow runs on any base index, so it would serve a wrongCOUNT(*)at HEAD from those stale class stats.Severity
Narrow — requires a transient base-store load failure during an incremental build that includes
rdf:type— but it is a correctness bug (silently wrong query result), and it precedes adding more class-stat fold paths (e.g. the bound-class fold), which would inherit the same exposure.Fix
Make the base-store load failure
return Err(IncrementalAbort(...))→ caller falls back to a full rebuild (which recomputes class + ref stats from scratch), mirroring the oversized-re-type gate (incremental.rs~line 2086).Minor sibling (perf-only, not correctness)
An all-quiet increment (no class deltas and no subject-property records) fails the Phase 3b gate (~line 1840);
id_hookfinalize setsclasses: Nonewith no carry-forward else-branch, so class stats are wiped → the fold declines and falls back to a scan (correct, just unaccelerated until the next rebuild). Worth a carry-forward of the prior class stats when there are no deltas.