Interval::overlap_duration overflows on unbounded intervals; in release this zeroes the stochastic sampler's acceptance probability

[cplonski20]

Version: unirust-rs 0.2.0, commit 47b317cee11c793545416679087f015eaf33d677.

Interval::overlap_duration does not guard the NEG_INF/POS_INF sentinels, so two Interval::all_time() values overflow the subtraction at src/temporal.rs:116. Interval::duration() right above it does guard them and returns None.

Repro

use unirust_rs::temporal::Interval;

fn main() {
    let a = Interval::all_time();
    let b = Interval::all_time();
    println!("{}", a.overlap_duration(&b));
}

Expected: 0, or a saturating value, or None. Anything that is not negative.

Actual, debug:

thread 'main' panicked at src/temporal.rs:116:13:
attempt to subtract with overflow

Actual, release: -1.

Why the release value matters

src/linker.rs:786 uses this as a sampling weight:

let overlap = interval.overlap_duration(cand_interval);
let cand_len = cand_interval.duration_or_zero();
let min_len = interval_len.min(cand_len).max(1);
let weight = (overlap as f64 / min_len as f64).min(1.0);
...
hash_frac < base_prob * (0.5 + 0.5 * weight)

With two all_time() intervals, duration_or_zero() is 0 on both sides, so min_len is 1 and weight is -1.0. The acceptance threshold becomes base_prob * 0.0, which is exactly 0.0, and hash_frac < 0.0 is never true. Every candidate pair with two unbounded intervals is dropped rather than sampled, silently and with no metric to notice it by.

stochastic_sampling is true in every preset in src/config/tuning.rs, and the path engages once a block exceeds sampling_threshold (200 to 800 by preset).

Interval::all_time() is not an exotic input. It is the public constructor for an attribute with no known validity window, and the crate uses it itself at src/graph.rs:452 and :600. My data has person names with no validity window at all, so every name descriptor gets all_time(), and common-surname blocks are exactly the ones large enough to trigger sampling.

A min(cand_len) on the weight would not fix it on its own, since duration_or_zero() already returns 0 for these and min_len is floored at 1. The subtraction itself needs the guard.

Smaller, separate

allen_relation at src/temporal.rs:196 returns Finishes for the (Less, Equal) arm and FinishedBy for (Greater, Equal). Allen's definitions, and the crate's own doc comment on AllenRelation::Finishes (a.start > b.start && a.end == b.end), give the opposite:

assert_eq!(
    allen_relation(&Interval::new(0, 100)?, &Interval::new(50, 100)?),
    AllenRelation::FinishedBy
); // returns Finishes

Every other pair in that match is oriented correctly. test_allen_relations covers only Overlaps, Meets and MetBy. Happy to split this into its own issue if you prefer.

[script3r]

Resolved by #6, merged into main as 3d99fe0. The merge automatically closed both duplicate reports (#4 and #5).

• overlap_duration() now uses saturating subtraction: two Interval::all_time() values return i64::MAX, preventing both the debug panic and the negative sampling weight in release builds. Oversized finite duration() values also saturate; infinite durations still return None.
• Finishes and FinishedBy are correctly oriented, with regression coverage for all 13 Allen relations.
• Fixed a related persistent-storage failure: unbounded and very wide intervals now use bounded temporal indexing instead of allocating one entry per day across the entire interval.

Validation passed for the full test suite, debug and release sampling regressions using PersistentStore, temporal queries after restart, distributed batch ingestion/query regressions, Clippy, and formatting. A five-shard, 1M-record before/after load test acknowledged every record with zero stream errors and no observed throughput regression (42.6K → 42.8K records/sec on the same machine).