You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Catalogue for the test-methodology review of 2026-08-28, run against v0.15 on develop. Filed as #1368–#1386.
What this review asked
Not "which test cases are missing" but "which methods does this suite not use". The suite was compared against how mature actor-model implementations in other ecosystems verify their own runtimes, and against the general distributed-systems testing literature.
The headline result is that the gaps are almost all methodological. There is no large body of missing test cases — core semantics are covered to a reasonable depth, and several areas are genuinely strong. What is absent is a set of techniques that find defects nobody thought to write a case for.
Where this suite is already ahead — do not "improve" these
Recorded so a later reader does not mistake the list below for a general verdict, and so none of this is accidentally traded away:
The persistence contract suite — 37 scenarios (19 journal / 10 snapshot / 8 durable-state) across 11 in-process harnesses and 10 live databases, with genuine capability negotiation so a backend can decline a scenario rather than pass it vacuously. tests/integration/brokers/lib/persistence-contract/.
MailboxProperties.test.ts — a real model-based test, driving 10 variants against a deliberately differently-implemented reference model (the priority model re-sorts rather than binary-searching, so a shared off-by-one cannot hide), comparing drain order and drop-reason logs.
The timing-discipline meta-tests — SleepRatchet.test.ts (three downward-only ledgers, its own TypeScript scanner, a sanity floor so a broken regex cannot satisfy every ceiling by reading nothing), AwaitConditionBudgets.test.ts, TimerTolerance.ts. Nothing in the comparison set has an equivalent.
A message can lose its prototype on a worker hop and fail on the wire, undetected
Ordering
Cheapest first, because in three cases the work is already written and merely on the wrong side of src/, and in two more the tool is already a dependency:
Everything else follows. #1378 is the largest single item and should start with a prototype establishing whether a controllable dispatcher is possible without changing production scheduling.
Runtime
Only #1374, #1376, #1377 and #1372 belong on the per-commit path. Byte fuzzing, interleaving search, mutation runs and the repeated-fault suites go to the nightly slot — .github/workflows/nightly-flakes.yml already has the shape for long jobs, including a watchdog and per-run aggregation.
Related open issues this review touched but did not duplicate
#200 (deterministic simulation — #1370 is its cheap prerequisite), #536 (public persistence testkit — closer to a move than the issue currently implies), #671 (probe assertions), #818 (soak and leak), #914 (#1384 would reproduce it), #1017 (#1369 and #1371 are the constructive successors), #1023 (fault primitives that #1379 and #1373 both want), #1176 (#1382 covers the seed-restart direction), #1225, #1291.
Method note
Every "missing" claim in the linked issues was checked by search against src/, package.json, the workflow files and the tracker — open and closed — rather than asserted from reading alone. Where a claim rests on reading, the file and line are quoted in that issue's verification section.
One correction worth recording, because it nearly went the other way: an intermediate research step reported that fast-check was not present in the project. It is — ^4.9.0, in seven files, landed by #543. Two issues in this catalogue (#1369, #1370) depend on that being true, and had the error survived they would have been written as "adopt a new dependency" rather than "use the one we have".
Catalogue for the test-methodology review of 2026-08-28, run against
v0.15ondevelop. Filed as #1368–#1386.What this review asked
Not "which test cases are missing" but "which methods does this suite not use". The suite was compared against how mature actor-model implementations in other ecosystems verify their own runtimes, and against the general distributed-systems testing literature.
The headline result is that the gaps are almost all methodological. There is no large body of missing test cases — core semantics are covered to a reasonable depth, and several areas are genuinely strong. What is absent is a set of techniques that find defects nobody thought to write a case for.
Where this suite is already ahead — do not "improve" these
Recorded so a later reader does not mistake the list below for a general verdict, and so none of this is accidentally traded away:
tests/integration/brokers/lib/persistence-contract/.MailboxProperties.test.ts— a real model-based test, driving 10 variants against a deliberately differently-implemented reference model (the priority model re-sorts rather than binary-searching, so a shared off-by-one cannot hide), comparing drain order and drop-reason logs.SleepRatchet.test.ts(three downward-only ledgers, its own TypeScript scanner, a sanity floor so a broken regex cannot satisfy every ceiling by reading nothing),AwaitConditionBudgets.test.ts,TimerTolerance.ts. Nothing in the comparison set has an equivalent.Terminatedsurviving a full mailbox ([Security] Death-watch Terminated is re-enqueued onto the bounded USER queue, so the default drop-head policy silently evicts it (oldest-first) and the watcher is permanently blinded, with no dead letter #729), the prepend/unstash path holding the bound ([Security] BoundedMailbox does not override prependUser, so unstashAll() unshifts up to 1024 envelopes straight past the capacity check, the overflow policy and the drop accounting #772), drop attribution before the actor instance exists ([Feature] A withMailbox-supplied BoundedMailbox reports no drops — actor_mailbox_dropped_total needs a chaining observer #1149).ParallelMultiNodeSpec— real OS threads behind nearly the same API as the in-process variant.Protocol.test.ts— asserts decode cost stays linear in bytes received, i.e. an algorithmic-complexity attack test.The catalogue
Methods the suite does not use
Testkit capability our users do not get
awaitConditionand the recording logger are internal onlyTestKit.withinis a post-hoc deadline onlyScenarios with no coverage
Terminatedfor the previous incarnationBecome.test.tshas four cases and none crosses a restartpreRestart/postRestart/ constructorBoundary semantics
Ordering
Cheapest first, because in three cases the work is already written and merely on the wrong side of
src/, and in two more the tool is already a dependency:fast-checkis already installed; both need an import, not a package.Everything else follows. #1378 is the largest single item and should start with a prototype establishing whether a controllable dispatcher is possible without changing production scheduling.
Runtime
Only #1374, #1376, #1377 and #1372 belong on the per-commit path. Byte fuzzing, interleaving search, mutation runs and the repeated-fault suites go to the nightly slot —
.github/workflows/nightly-flakes.ymlalready has the shape for long jobs, including a watchdog and per-run aggregation.Related open issues this review touched but did not duplicate
#200 (deterministic simulation — #1370 is its cheap prerequisite), #536 (public persistence testkit — closer to a move than the issue currently implies), #671 (probe assertions), #818 (soak and leak), #914 (#1384 would reproduce it), #1017 (#1369 and #1371 are the constructive successors), #1023 (fault primitives that #1379 and #1373 both want), #1176 (#1382 covers the seed-restart direction), #1225, #1291.
Method note
Every "missing" claim in the linked issues was checked by search against
src/,package.json, the workflow files and the tracker — open and closed — rather than asserted from reading alone. Where a claim rests on reading, the file and line are quoted in that issue's verification section.One correction worth recording, because it nearly went the other way: an intermediate research step reported that
fast-checkwas not present in the project. It is —^4.9.0, in seven files, landed by #543. Two issues in this catalogue (#1369, #1370) depend on that being true, and had the error survived they would have been written as "adopt a new dependency" rather than "use the one we have".