Symptom
it_values_type_deleted_repro::values_bound_type_after_delete_incremental_index_timeline (bundled into fluree-db-api/tests/grp_misc.rs via #[path], source at fluree-db-api/tests/it_values_type_deleted_repro.rs:202) fails roughly 1 in 6 thread-parallel cargo test --test grp_misc runs with:
Internal("failed to load binary index: dict branch: too small for header")
It passes reliably single-threaded (--test-threads=1) and was not observed failing under nextest's process-per-test execution during the same gate batteries.
Shape of the failing timeline
The test drives the production-like background-indexer sequence: insert across two commits → build_and_publish_index → reload ledger → wipe → incremental build_and_publish_index folding the retractions → reload → re-insert → index → reload, asserting VALUES/type shapes agree at each step. The failure is on a reload step: the freshly published binary index's dict branch fails the header-size check when read back, which points at a reload race (reader observing a partially-written or stale dict-branch artifact) rather than anything in the test's own assertions — i.e. a fluree-db-core binary-index load/publish race surfaced by CPU contention, not a query bug.
Discovery context
Surfaced during the perf-series gate batteries (PR #1486 body records it as an explicitly out-of-scope, pre-existing flake — that PR only moves an unrelated test between binaries and touches no engine code). The failure rate was measured while grp_misc's ~240 bundled tests ran thread-parallel in one process, so timing pressure from sibling tests appears to be the trigger.
Suggested next steps for the binary-index owner
- Reproduce with
cargo test -p fluree-db-api --test grp_misc values_bound_type_after_delete_incremental_index_timeline looped under parallel sibling load (or the full grp_misc repeated ~10×).
- Audit the publish→reload boundary in the binary-index dict-branch writer/loader for a missing ordering guarantee (rename-before-flush, non-atomic publish of the branch file, or a cached header length read against a superseded artifact).
Symptom
it_values_type_deleted_repro::values_bound_type_after_delete_incremental_index_timeline(bundled intofluree-db-api/tests/grp_misc.rsvia#[path], source atfluree-db-api/tests/it_values_type_deleted_repro.rs:202) fails roughly 1 in 6 thread-parallelcargo test --test grp_miscruns with:It passes reliably single-threaded (
--test-threads=1) and was not observed failing under nextest's process-per-test execution during the same gate batteries.Shape of the failing timeline
The test drives the production-like background-indexer sequence: insert across two commits →
build_and_publish_index→ reload ledger → wipe → incrementalbuild_and_publish_indexfolding the retractions → reload → re-insert → index → reload, asserting VALUES/type shapes agree at each step. The failure is on a reload step: the freshly published binary index's dict branch fails the header-size check when read back, which points at a reload race (reader observing a partially-written or stale dict-branch artifact) rather than anything in the test's own assertions — i.e. afluree-db-corebinary-index load/publish race surfaced by CPU contention, not a query bug.Discovery context
Surfaced during the perf-series gate batteries (PR #1486 body records it as an explicitly out-of-scope, pre-existing flake — that PR only moves an unrelated test between binaries and touches no engine code). The failure rate was measured while
grp_misc's ~240 bundled tests ran thread-parallel in one process, so timing pressure from sibling tests appears to be the trigger.Suggested next steps for the binary-index owner
cargo test -p fluree-db-api --test grp_misc values_bound_type_after_delete_incremental_index_timelinelooped under parallel sibling load (or the fullgrp_miscrepeated ~10×).