Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

BLQL compares two Int64 values through double

Open Beginner friendly
  • Is something wrong?
#268 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@CaffeinatedCoder is already working on this.

Since Oct 17, 2026.

  • #285 by @CaffeinatedCoder — open

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
82/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
csharp
Domain
backend, databases

Research direction

Read src/BLite.Core/Query/Blql/BsonValueComparer.cs, especially Compare and its numeric conversion paths. Use the repro values in the issue to verify integer comparisons around 2^53 and long.MaxValue, then run the DynamicCollection oracle tests in tests/BLite.Tests/Oracles/DynamicDifferentialTests.cs. Done when those cases compare integers exactly and the oracle rows pass.

Written by the indexing model from the issue text.

Description

area/linq bug package/core triage

BLQL compares two Int64 (or Int32 and Int64) values by converting both to double, so it cannot tell apart integers above 2^53 that differ by less than their double spacing: {t: {$gt: long.MaxValue - 1}} does not match long.MaxValue, and {t: 2^53} matches 2^53 + 1. The comparer's own summary says integers are compared exactly.

Found by the DynamicCollection oracle tests (tests/BLite.Tests/Oracles/DynamicDifferentialTests.cs, #272), which carry the affected rows (4: indexed/blql and plain/blql, both oracles, total > long.MaxValue - 1: expected the one document with long.MaxValue, got none) as a known candidate until this is fixed.

Repro

// t: long.MaxValue ("max"), long.MaxValue - 1 ("max-1"), 2^53 + 1 ("2^53+1"), all stored as Int64
col.Query(BlqlFilter.Gt("t", long.MaxValue - 1)).ToList();   // expected [max],   actual []
col.Query(BlqlFilter.Eq("t", long.MaxValue - 1)).ToList();   // expected [max-1], actual [max, max-1]
col.Query(BlqlFilter.Eq("t", 1L << 53)).ToList();            // expected [],      actual [2^53+1]

Expected: exact comparison of integers, as BsonValueComparer's summary says: "Within the same numerical family, values are compared numerically: exactly (as decimal) when neither side is a Double, through double otherwise" (src/BLite.Core/Query/Blql/BsonValueComparer.cs:11-12). LINQ and the typed collection compare long exactly.

Actual: see above. The indexed collection is wrong too: its scan bounds are exact (IndexKey(long)), and the residual filter then drops the right document.

Mechanism (verified on 0450b97)

BsonValueComparer.Compare takes the exact path only when one side is a Decimal128 (BsonValueComparer.cs:29-33); Int32 and Int64 pairs fall through to ToDouble(a).CompareTo(ToDouble(b)) (:35), which rounds above 2^53.

Affected versions: since BLQL (a86d458, v1.9.0). Reproduced on v5.2.3 / 0450b97.

Fix considerations

  • Compare as decimal (or long) whenever neither side is a Double, as the summary describes: the condition at :31 drops the Decimal128 requirement.
  • A Double against an Int64 still goes through double; comparing those exactly (as MongoDB does) is a further step and not what the summary promises.
  • The evaluator's cross-type range matching (#267) is in CompareFilter, a separate fix.

Related: #150 and #222 (closed, the typed decimal and cross-type bound fixes), and the other BLQL rows of the same tests: #264, #265, #266, #267.

Dominant language
C#
Stars
66
Forks
6
Avg merge
1d 2h
Merged PRs (30d)
43

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from EntglDb/BLite

All issues in EntglDb/BLite

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.