Repository navigation
test(core): make the filter parity suite able to catch a wrong created_at bound - #1042
Conversation
🦋 Changeset detectedLatest commit: 8b131dd The changes in this PR will be included in the next version bump. This PR includes changesets to release 0 packagesWhen changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the
|
[Low impact] This PR appears safe to merge.
|
Closes #981 — see the closing note at the end: the keyword is inert on this base.
The filter parity suite could not see a wrong
created_atbound. Measured before this change: moving the bound fromCREATED_AT_LIMIT(10¹⁰) to 10⁸ left the suite at 54 passed / 0 failed, because the nearest invalid row was1_672_295_751_103— 167× the real limit — and every other row sat far below 10⁸.The sharper half, which the issue did not measure: a filter-only mutation (
filter.rs:487→CREATED_AT_LIMIT / 100, decoder untouched) left the entire workspace at 942 passed / 0 failed. So a wrong filter bound was caught by nothing anywhere, not merely missed by this suite.What changed
Four rows in a new section of
crates/nostream-core/tests/filter_schema_parity.rs, split by direction:since/until=9_999_999_999/100)since/until=10_000_000_000Two files,
+54/−0: the tests (+46) and an empty-fronted changeset (+8). No production line moved —git diff --stat 0fa4150..8b131dd -- crates/nostream-core/src/is empty.The oracle, run as inversions rather than argued
Each in its own
git archivecopy with its ownCARGO_TARGET_DIR, mutation confirmed by grep before running:validation.rs:20→ 10⁸filter.rs:487→CREATED_AT_LIMIT / 100validation.rs:20→ 10¹²A and B never list the refusal rows; C never lists the acceptance rows. That asymmetry is the point of splitting by direction: a row written to the wrong side would show up as a green inversion rather than a silent one.
Parity suite 54 → 58.
Where the numbers come from
10¹⁰is the capture's own predicate —Math.log10(value) < 10insrc/schemas/base-schema.ts— evaluated rather than read: node accepts9999999999and refuses10000000000. The capture's table has no row near the bound either, which is why the suite agreed with itself.The literals cannot be shared with the implementation:
CREATED_AT_LIMITispub(crate)and a test is a separate crate. That is not a limitation to work around — an expectation read from the constant would have stayed green under all three inversions above.Left uncovered, stated
9_999_999_999) is still untested on the event surface. A decoder-only ceiling between1_700_000_000and10_000_000_000would be invisible; the shared constant is now pinned by these four rows, so the two cannot drift apart silently.pnpm exec changeset statuswas not run (nonode_modulesin the worktree); CI'sChangeset Requiredis its first real run.Note on the keyword
Closes #981does nothing here: GitHub closes by keyword only when the pull request targets the default branch, and this targetsrewrite/main. Whoever merges closes the issue by hand and reads the state back.