Tested against: origin/main @ 8e84501a (post-v0.3.0 main head, 2026-07-07)
Severity: High — per-record history reads are the primary query shape on
a BITEMPORAL collection; every such read silently returns empty, making the
audit surface unusable while writes keep succeeding.
Summary
On a BITEMPORAL document_strict collection, a version-history scan
(AS OF SYSTEM TIME NULL) that also carries a WHERE predicate
returns 0 rows silently. The bare AS OF SYSTEM TIME NULL scan on
the same collection returns the full version set with correct
_ts_system / _ts_valid_from / _ts_valid_until projections, so the
versioned store itself is intact — only the predicate-carrying scan
path drops everything. ORDER BY makes no difference. The result also
comes back with a placeholder result column header instead of the
collection's columns, suggesting the query resolves to an empty
synthetic result rather than a filtered scan.
Regression relative to 67c4572d, where AS OF SYSTEM TIME NULL WHERE id = ... returned that record's versions; plausibly fallout of the
recent unification of bitemporal document scans onto a shared pipeline.
Repro
CREATE COLLECTION asof_repro (id TEXT PRIMARY KEY, v TEXT, BITEMPORAL) ENGINE = document_strict;
INSERT INTO asof_repro (id, v) VALUES ('a','one');
UPDATE asof_repro SET v = 'two' WHERE id = 'a';
SELECT * FROM asof_repro AS OF SYSTEM TIME NULL;
-- id | _ts_system | _ts_valid_from | _ts_valid_until | v
-- a | 1783400895366 | -9223372036854775808 | 9223372036854775807 | one
-- a | 1783400895370 | -9223372036854775808 | 9223372036854775807 | two
-- (2 rows) -- full history, correct
SELECT * FROM asof_repro AS OF SYSTEM TIME NULL WHERE id = 'a';
-- result
-- (0 rows) -- WRONG: expected the same 2 versions
SELECT * FROM asof_repro AS OF SYSTEM TIME NULL WHERE id = 'a' ORDER BY _ts_system;
-- (0 rows) -- WRONG
Expected
AS OF SYSTEM TIME NULL + WHERE returns the version rows matching
the predicate — filtering a history scan must not differ semantically
from filtering a plain scan.
- The result carries the collection's real column set (as the bare
scan already does), not a placeholder result column.
Files (best-guess)
nodedb/src/data/executor/handlers/document/read/fetch.rs — new
shared fetch pipeline; the predicate path appears not to be wired for
all-versions scans.
nodedb/src/data/executor/dispatch/document.rs — dispatch may route
predicate-carrying AS OF reads to a path that ignores the version
store.
Operational context
The whole point of a BITEMPORAL collection is answering "what did this
record look like over time" — i.e. AS OF SYSTEM TIME NULL WHERE <key>.
With that shape returning empty, audit-trail consumers must scan the
entire history of every record and filter client-side, which is
unbounded on a growing audit log.
Tested against:
origin/main @ 8e84501a(post-v0.3.0 main head, 2026-07-07)Severity: High — per-record history reads are the primary query shape on
a BITEMPORAL collection; every such read silently returns empty, making the
audit surface unusable while writes keep succeeding.
Summary
On a BITEMPORAL
document_strictcollection, a version-history scan(
AS OF SYSTEM TIME NULL) that also carries aWHEREpredicatereturns 0 rows silently. The bare
AS OF SYSTEM TIME NULLscan onthe same collection returns the full version set with correct
_ts_system/_ts_valid_from/_ts_valid_untilprojections, so theversioned store itself is intact — only the predicate-carrying scan
path drops everything.
ORDER BYmakes no difference. The result alsocomes back with a placeholder
resultcolumn header instead of thecollection's columns, suggesting the query resolves to an empty
synthetic result rather than a filtered scan.
Regression relative to
67c4572d, whereAS OF SYSTEM TIME NULL WHERE id = ...returned that record's versions; plausibly fallout of therecent unification of bitemporal document scans onto a shared pipeline.
Repro
Expected
AS OF SYSTEM TIME NULL+WHEREreturns the version rows matchingthe predicate — filtering a history scan must not differ semantically
from filtering a plain scan.
scan already does), not a placeholder
resultcolumn.Files (best-guess)
nodedb/src/data/executor/handlers/document/read/fetch.rs— newshared fetch pipeline; the predicate path appears not to be wired for
all-versions scans.
nodedb/src/data/executor/dispatch/document.rs— dispatch may routepredicate-carrying AS OF reads to a path that ignores the version
store.
Operational context
The whole point of a BITEMPORAL collection is answering "what did this
record look like over time" — i.e.
AS OF SYSTEM TIME NULL WHERE <key>.With that shape returning empty, audit-trail consumers must scan the
entire history of every record and filter client-side, which is
unbounded on a growing audit log.