Found while fixing #9371. Not fixed there — that PR fixes the product defect that caused the teardown race, and this is a separate (and much smaller) ordering issue in the test's own harness.
The shape
examples/app-showcase/test/approval-resume-relation-expand.test.ts:71-78:
afterEach(async()=>{while(openDrivers.length){try{awaitopenDrivers.pop()?.disconnect?.();}catch{/* noop */}}while(openKernels.length){try{awaitopenKernels.pop()?.shutdown?.();}catch{/* noop */}}});Drivers are disconnected first, then the kernels are shut down. So every kernel runs its whole teardown — hook dispatch, each plugin destroy(), each service's drain of in-flight work — against a driver that is already gone. The correct order is the reverse: stop the producers, then remove the resource they depend on.
Measured consequence
Instrumenting console.* across the showcase suite (one run, all 21 files): 348 console calls, 294 of them from this one file, and 120 of the 348 are [sql-driver] DATABASE_ERROR — the backend refused a read on … emitted through SqlDriver's console fallback logger. A large share of those are reads issued during teardown against the disconnected driver.
That is not a correctness problem for the assertions — every test passes — but under vitest each console.* is an RPC round-trip to the main process (onUserConsoleLog), so it is pure cost, and the depth of that queue is one of the two things that widened the teardown window in #9371.
Suggested repair
Swap the two loops. packages/services/service-messaging/src/plugin-shutdown-stops-dispatchers.test.ts (added in the #9371 PR) does it in the correct order and says why in a comment.
⚠️ Worth re-measuring the console volume after the swap rather than assuming: the fix in #9371 already removed a large chunk of this traffic (console RPC round-trips over 48 loaded runs of this file fell 6574 → 3456), so the remaining share attributable to ordering is unknown.
Found while fixing #9371. Not fixed there — that PR fixes the product defect that caused the teardown race, and this is a separate (and much smaller) ordering issue in the test's own harness.
The shape
examples/app-showcase/test/approval-resume-relation-expand.test.ts:71-78:Drivers are disconnected first, then the kernels are shut down. So every kernel runs its whole teardown — hook dispatch, each plugin
destroy(), each service's drain of in-flight work — against a driver that is already gone. The correct order is the reverse: stop the producers, then remove the resource they depend on.Measured consequence
Instrumenting
console.*across the showcase suite (one run, all 21 files): 348 console calls, 294 of them from this one file, and 120 of the 348 are[sql-driver] DATABASE_ERROR — the backend refused a read on …emitted throughSqlDriver's console fallback logger. A large share of those are reads issued during teardown against the disconnected driver.That is not a correctness problem for the assertions — every test passes — but under vitest each
console.*is an RPC round-trip to the main process (onUserConsoleLog), so it is pure cost, and the depth of that queue is one of the two things that widened the teardown window in #9371.Suggested repair
Swap the two loops.
packages/services/service-messaging/src/plugin-shutdown-stops-dispatchers.test.ts(added in the #9371 PR) does it in the correct order and says why in a comment.