Summary
unitTests/resources/query.test.js → "Querying through Resource API > Sorting > Query data in a table with narrow constraint sorting on different property" intermittently fails. In the failing job the test passed on the first suite pass and failed on the second pass within the same job, confirming nondeterminism. Re-running goes green.
Exact error
TypeError [ERR_INVALID_ARG_TYPE]: The "message" argument must be one of type string or function. Received undefined
at innerFail (node:internal/assert/utils:135:11)
at assert (node:assert:186:3)
at Context.<anonymous> (unitTests/resources/query.test.js:905:4)
Line 905 is a bare assert(QueryTable.primaryStore.readCount - start_count < 25) (no message arg). The ERR_INVALID_ARG_TYPE is a masking artifact of the bare assert() failing — the real failure is the read-count efficiency assertion (the sorted, narrow-constraint query read more rows than the < 25 budget allows), which is sensitive to cache/index warm-state and load.
Why it's a flake
The assertion is a performance / read-count heuristic, not a correctness check; it depends on store warm-state that varies under CI contention. Same commit passes on re-run and even passed earlier in the same job.
Suggested fix direction
- Give the
assert a message so future failures are legible, and/or make the read-count budget tolerant of cold-cache runs (or assert behavior / result-order instead of read count).
Affected job / runtime
Unit Test (Node.js v26) (mechanism not runtime-specific).
Evidence
Filed by Claude (Opus 4.8) during CI flake triage while shepherding #1363/#1371/#1374.
Summary
unitTests/resources/query.test.js→ "Querying through Resource API > Sorting > Query data in a table with narrow constraint sorting on different property" intermittently fails. In the failing job the test passed on the first suite pass and failed on the second pass within the same job, confirming nondeterminism. Re-running goes green.Exact error
Line 905 is a bare
assert(QueryTable.primaryStore.readCount - start_count < 25)(no message arg). TheERR_INVALID_ARG_TYPEis a masking artifact of the bareassert()failing — the real failure is the read-count efficiency assertion (the sorted, narrow-constraint query read more rows than the< 25budget allows), which is sensitive to cache/index warm-state and load.Why it's a flake
The assertion is a performance / read-count heuristic, not a correctness check; it depends on store warm-state that varies under CI contention. Same commit passes on re-run and even passed earlier in the same job.
Suggested fix direction
asserta message so future failures are legible, and/or make the read-count budget tolerant of cold-cache runs (or assert behavior / result-order instead of read count).Affected job / runtime
Unit Test (Node.js v26)(mechanism not runtime-specific).Evidence
Filed by Claude (Opus 4.8) during CI flake triage while shepherding #1363/#1371/#1374.