callcenter: fix the graph_table fixture's classid + tail mint (2 red tests) - #897
Conversation
…tests) `cargo test -p lance-graph-callcenter --features query` was 209/2 red. Both failures were the same defect, and it is NOT a DataFusion-54 regression: the assertion that fires is `num_rows() == 0` vs 4, decided before DataFusion is involved. `OSINT_GOTHAM.classid` resolves to `CLASSID_OSINT_V3` (0x0701_1000) under the default `guid-v3-tail` feature, falling back to the V1 `CLASSID_OSINT` (0x0700_0000) only with the feature off. The fixture minted its two rows with the V1 constant written out literally, so `project_snapshot`'s `classid == domain.classid` filter -- the codex-P1 cross-class leak guard -- matched zero rows and every assertion below it ran against an empty snapshot. Fixing only the classid would have been half a fix: with a V3 classid, `family_of` reads the tail via `family_v2()`, so a `NodeGuid::new` (V1 tail) key would carry the family in the wrong bits even once the filter passed. The fixture now mints through `mint_for(classid_read_mode(c).tail_variant, ...)` with the classid taken from the domain -- which is what the CANON requires of every new mint anyway -- so it is correct under either feature setting rather than encoding one branch of it. 211/211 green under `--features query`. This is V1->V3 migration residue (ISS-V1-TAIL-RESIDUE), not new breakage. It survived because nothing runs this feature combination: the same coverage hole that let `vsa_udfs` and `transcode::ontology_table` report clippy EXIT=0 earlier in this arc while never being compiled. Recorded as E-A-FEATURE-CONDITIONAL-CLASSID-SILENTLY-EMPTIED-A-FIXTURE-1; the CI gap itself is still open.
|
Warning Review limit reached
Next review available in: 1 minute You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_ff92246c-6f55-4f74-8467-07c768425227) |
…nd gate)
Nothing in CI ran this crate, and `default = []` means even a bare
`cargo test -p lance-graph-callcenter` would compile almost none of it and
report a green it had not earned. Two defects rode through that gap on
2026-08-05:
- clippy EXIT=0 over `vsa_udfs` and `transcode::ontology_table`, which were
never compiled (both behind `query` / `query-lite`);
- 2 genuinely failing tests -- the `graph_table` fixture minted rows with the
V1 `CLASSID_OSINT` while `OSINT_GOTHAM.classid` resolves to
`CLASSID_OSINT_V3` under the default `guid-v3-tail`, so the class filter
matched zero of two rows and every assertion ran against an empty snapshot
(fixed in #897).
Two steps, both mandatory, matching the deepnsm posture: gate it WHILE it is
clean so it cannot regress. Verified locally on this tree before adding them --
clippy 0 errors, tests 211/211 -- so neither step lands red.
Advisory was considered and rejected: the advisory tier exists for crates
carrying pre-existing debt to be paid down (lance-graph core, bgz-tensor).
This crate has none under this feature today.
A green run that never compiled the module is not coverage. Same shape the repo
has already closed for deepnsm, supervisor, ogar and bgz-tensor -- this one is
subtler only because the missing coverage was a FEATURE, not a crate.
2 participants
What this fixes
cargo test -p lance-graph-callcenter --features querywas 209 passed /2 failed. Both failures are one defect in the
graph_tabletest fixture.This PR fixes it (211/211) and records the finding.
It is not a DataFusion-54 regression. The assertion that fires is
num_rows() == 0against an expected 4 — decided inproject_snapshot, beforeDataFusion is involved at all.
The defect, in two links
soa_graph::OSINT_GOTHAM.classidresolves toNodeGuid::CLASSID_OSINT_V3(
0x0701_1000) under the defaultguid-v3-tailfeature, falling back tothe V1
NodeGuid::CLASSID_OSINT(0x0700_0000) only with the feature off.The fixture minted its two rows with the V1 constant spelled out literally,
so
project_snapshot'sclassid == domain.classidfilter — the codex-P1guard against cross-class leakage — matched zero of two rows, and every
assertion below ran against an empty snapshot.
Fixing only the classid would be half a fix. With a V3 classid,
family_ofreads the tail through
family_v2(), so aNodeGuid::newkey (V1 tail,family:u24at bytes 10..13) would carry the family in the wrong bits evenafter the filter passed.
The fixture now mints through
mint_for(classid_read_mode(c).tail_variant, …)with the classid taken from the domain — which is what the CANON requires of
every new mint anyway. Reading both the classid and the tail variant off the
domain keeps it correct under either feature setting, instead of encoding one
branch of a feature-conditional constant.
The part that is still open
This is V1→V3 migration residue (
ISS-V1-TAIL-RESIDUE), not new breakage. Itsurvived because nothing runs this feature combination — the same coverage
hole that earlier in this arc let
vsa_udfsandtranscode::ontology_tablereport clippy
EXIT=0while never being compiled, both being behindquery/query-lite.The generalization, recorded as
E-A-FEATURE-CONDITIONAL-CLASSID-SILENTLY-EMPTIED-A-FIXTURE-1: a feature-gatedmodule is not covered by a green run that never compiled it, and a
feature-conditional constant is not pinned by a test that spells one of its
branches. The CI gap itself is not closed by this PR — no job runs
--features querytoday.Testing
cargo +1.97.1 test -p lance-graph-callcenter --features query --lib→211 passed, 0 failed (was 209/2).