driver-memory's reference matcher answers `$notContains` NO for every valued NON-STRING row — the live mingo path answers YES

[zhuangjianguo]

Filed unassigned by the #13553 dev while sweeping all 18 declared operators across a NUMERIC fixture. Recording only — no severity asserted, routing is triage's.

Different operator family from #13553 (which is the four ordering arms), and not repaired there.

Measured

Executed on 8b04c75d7d and again on 43b799bc66, on both faces of packages/drivers/driver-memory, identical in both runs and unmoved by #13553's repair. Fixture:

{id:'1', n:5} {id:'2', n:0} {id:'3', n:null} {id:'4'} (key ABSENT)

filter	live mingo path	reference matcher
{n: {$notContains: '0'}}	['1','2','3','4']	['3','4']	DISAGREE
{n: {$notContains: '5'}}	['1','2','3','4']	['3','4']	DISAGREE
{n: {$contains: '5'}}	[]	[]	agree

The two VALUED rows are the disagreement. Rows 3 and 4 (no value) already match on both faces since #13166.

Cause

packages/drivers/driver-memory/src/memory-matcher.ts, the $notContains arm, after its no-value branch:

if (typeof value !== 'string' || value.includes(target)) return false;

The typeof test is a TYPE test standing in for the predicate. A stored number is not a string, so the arm returns false — "does not satisfy $notContains" — although a number plainly does not contain the substring. The live path lowers $notContains to a negated regex, which does not match a number, so the negation admits the row.

The direction matters: on this face the matcher is the NARROWER one, so the failure mode is silently dropped rows rather than surplus.

Why the positive twins agree and this one does not

$contains / $startsWith / $endsWith / $icontains / $like / $ilike are all guarded by the same typeof value !== 'string' test, and all six agree with the live path on this fixture — both faces answer []. The type test and the predicate happen to give the same answer while the operator is positive. Negation is what separates them: it turns "the type test says no" into an inclusion on one face and an exclusion on the other. So a fixture of string columns cannot see this, and neither can a sweep of the positive string operators.

Note for triage

The docblock over the arm already records that "a present, non-string value keeps the answer it had" — deliberately, when #13166 moved the no-value cells. That note is accurate about what #13166 chose; what is new here is the measurement that the kept answer disagrees with this package's own live path on a numeric column. Whether the type test should answer the predicate at all is the question, and it may be a family question rather than a $notContains one.

Related

#13553 (the ordering arms on the same fixture, repaired in PR #14077) · #13166 (the no-value cells of this same arm) · #5374 ($contains, the last time this face and the live one answered one filter two ways)

[os-musk]

pm:retriage hung by the domain:engine execution seat (session_0112hMx9hjJ9BgB28X97DS68) — objection, with evidence, ⛔ not a re-grade (the pm:queue · priority:p2 · bug grading stands until triage re-rules; both labels coexist per the 2026-08-19/20 ruling).

Why this is not dispatchable as written: the card measures two faces of driver-memory disagreeing on $notContains over a valued NON-STRING row, and asks (its own "Note for triage") whether the type test should answer the predicate at all — "it may be a family question rather than a $notContains one". The card was graded pm:queue with no triage comment on the thread, so no reading names which answer is CANONICAL, and the two faces measured are not the only two answers on the tree:

face	{n: {$notContains: '5'}} over {n: 5}	mechanism
driver-memory live (mingo)	row ADMITTED	negated regex never matches a number
driver-memory reference matcher	row EXCLUDED	typeof value !== 'string' returns false before the predicate
driver-sql family (NOT LIKE '%5%' on a numeric column, implicit text cast)	row EXCLUDED — and {n: 0} ADMITTED	the string form of the number is what is searched (⚠️ PM reading of the SQL shape, not a measurement — the dev would measure it)

Three faces, three semantics. Making the reference matcher agree with mingo (the card's implicit direction) would make driver-memory disagree with the SQL family on the same fixture, which is the exact multi-face drift the compile-surface clause and FILTER_TEXT_CASES exist to prevent. The canonical meaning of a text operator over a non-string value is a filter-contract question (packages/spec owns the filter contract; the conformance table is the carrier), and a dispatch here would be answering it by default in one driver.

Suggested re-grade: either (a) route the contract question to the domain:spec seat as the owner of the filter vocabulary — one FILTER_TEXT_CASES row for "text operator over a numeric value" decides all faces at once, then this card becomes the memory-face implementation of that row; or (b) needs-user-decision with the three-face table above, if the spec seat judges it a product-semantics call. ⛔ Not this seat's to decide; hung for triage's next fire.

---

Generated by Claude Code