[nissa-seru]

TL;DR: vector 34c now checks how many store syncs its 300 coalesced messages make, at least one and at most one a message, instead of how long they take. The time follows the disk and the host's load. On a loaded Linux host the test failed at 34.1 s with nothing wrong in the code, and with each store sync slowed by 120 ms it failed in both runs, since 300 syncs at 120 ms take 36 s, past the 30 s bound. The count is the cost #196's review was about, and a regression to more than one sync a message on the path this test drives fails it on any machine. Test-only; no changelog fragment.

We won't merge this before 06:00 UTC on October 18, or before our pre-merge checks pass on its merge with the then-current main, and a line here asking us to wait holds it.

Problem

"#196 finding 2 / vector 34c: a busy channel never hits a subject cap" sends 300 coalesced channels/incoming messages one at a time, then asserts that they took under 30 s. Each acceptance awaits a durable commit, one store.sync(), so the time is mostly fsync time and CPU contention. On Linux with Node 24.22.0, at load averages of 57 to 78, main's version took 10.8 s to 34.1 s over six runs, three of them beside six node -e "for(;;){}" loops, and failed once, at 34.1 s. With every store.sync() slowed by 120 ms, through a preload that busy-waits inside it (below), it failed both times, at 44.2 s and 46.7 s.

The bound came from #196's review, which measured 85 ms a message on this path because its journal synced the store for each of three operations per message. That cost is a count of syncs per message, and the wall-clock bound couldn't tell it apart from a slow disk.

Changes

test/mcpl-coalescing.test.ts, vector 34c only, in two commits: 10314c5d replaces the time bound with the count, and f446e8d0 answers an internal review of it.

• The test counts every store.sync() call during the 300 sends, and asserts at least one and at most 300. The ceiling lets commits shared between acceptances pass. The floor fails a run in which all the acceptances stop committing, or the count stops seeing their commits. In every run of the test as committed, below, the count was exactly 300.
• Its fixture sets syncIntervalMs: 0. start() arms the periodic store sync, and this fixture never calls it, so the option changes nothing today. It keeps that sync off if a later fixture calls start().
• It reports the time beside the count. It no longer bounds per-message cost that isn't a store sync. Each send still has the fixture's reply deadline, which turns a reply that never comes into a failure, since CI runs without a test timeout.
• Its functional checks are unchanged: every message is accepted, nothing wakes the agent before the mention, and the one turn after the mention reads both the first message and the mention.

What each part is for

The test targets the repeated store-sync work reported in #196's review. It replaces the elapsed-time bound with bounds on the number of store.sync() calls.

• The count during the 300 sends. A wrapper counts calls, and the test snapshots the count before draining the framework or sending the mention. This observes the selected operation directly. A looser wall-clock bound would still mix extra sync calls with host and disk speed; removing the bound would drop the guard.
• The ceiling of 300 calls for 300 sends. A mutation that calls host.commit twice per acceptance reports 600 sync calls and fails. Unlike an exact count of 300, the ceiling permits fewer calls so a later implementation sharing commits between acceptances can satisfy this count check.
• The floor of at least one call. One assertion rejects an interval with zero observed calls, whether the acceptance path stopped calling sync() or the counter stopped seeing those calls.
• syncIntervalMs: 0. It changes nothing in these runs because the fixture never calls start(). It explicitly selects no periodic store-sync timer if a later fixture does call start(), keeping that source of calls out of the intended measurement.
• The time in the console line. Kept as information for whoever investigates a slow run. Nothing asserts on it.

Cut: the 30 s assertion over the 300 sends. The new count bounds neither elapsed time nor work other than store.sync() calls.

Tests

At f446e8d0, on Linux with Node 24.22.0:

• Alone, 2 runs at load averages of 27 to 31: 5.3 s and 6.8 s, 300 store syncs each, both passing.
• The coalescing file: 67 of 67 on Node 24.22.0 and on Node 20.20.2, with typecheck and build clean.
• With each acceptance's commit removed (the await this.host.commit?.() in PushCoalescer.acknowledge()), it fails at the floor: "300 coalesced messages made no store sync: the acceptances didn't commit, or the count can't see their commits".
• With each acceptance committing twice, it fails at the ceiling: "300 coalesced messages made 600 store syncs, more than one a message".

At 10314c5d, whose test has the same count and ceiling without the floor:

• Without added load, 3 runs at load averages of 74 to 77: 14.6 s to 27.3 s, 300 store syncs each, all passing.
• With each store.sync() slowed by 120 ms, 2 runs: 60.1 s and 61.1 s, 300 store syncs, both passing. main's version failed both of its runs on time, at 44.2 s and 46.7 s at load averages of 40 to 43.
• Beside six busy loops, 6 runs at load averages of 64 to 86: 18.3 s to 45.9 s, 300 store syncs each, all passing. Two of them, at 30.9 s and 45.9 s, took longer than the old bound allowed.
• Full check at 10314c5d, with main (14e25dc0) run the same way beside it, on Linux at load averages between about 15 and 45. Typecheck and build are clean. Each file on its own, without --test-force-exit, passes 2378 of 2378 tests on Node 24.22.0 and on Node 20.20.2, the same count as main. npm test, as CI runs it on Node 24.22.0, passed 2352 of 2352, and the same forced run with TAP passed 2334 of 2334 on Node 24 and 2378 of 2378 on Node 20. Forced runs report fewer tests because --test-force-exit can end a file before all its tests report (npm test's --test-force-exit can end a test file before its tests report, so a short run still passes #294). Our run of CI's unforced step passed 105 of 105 on both Nodes. In main's run of the same commands, vector 34c failed on time on Node 20, beside other tests that fail under load.

The slowed syncs come from Nigel-2654's preload, which wraps each framework's store.sync() and busy-waits F61_SYNC_DELAY_MS before calling it, since a slow fsync holds the event loop the same way (F61_SYNC_DELAY_MS=120 node --import ./f61-sync-delay.mjs --test-name-pattern='vector 34c' dist/test/mcpl-coalescing.test.js):

f61-sync-delay.mjs

// F61 probe preload: each durable commit (the framework store's sync) takes
// F61_SYNC_DELAY_MS longer, as on a loaded disk, and is counted per framework.
// The delay is a synchronous wait because store.sync() is synchronous: a slow
// fsync holds the event loop the same way.
// Use: node --import <this file> <test file>, from the agent-framework root.
import { resolve } from 'node:path';
import { pathToFileURL } from 'node:url';

const delayMs = Number(process.env.F61_SYNC_DELAY_MS ?? 0);
// F61_HANG_COMMITS=1: the coalescer's durable commit never resolves, so the
// first coalesced admission waits forever while the event loop stays free:
// a host that never answers, with timers still able to fire.
const hangCommits = process.env.F61_HANG_COMMITS === '1';
const { AgentFramework } = await import(pathToFileURL(resolve(process.cwd(), 'dist/src/framework.js')).href);
const create = AgentFramework.create;
let n = 0;
globalThis.__f61 = { delayMs, frameworks: [], current: null };
AgentFramework.create = async function (config) {
  const fw = await create.call(this, config);
  const store = fw.store;
  const sync = store.sync.bind(store);
  const rec = { id: ++n, syncs: 0, syncMs: 0 };
  globalThis.__f61.frameworks.push(rec);
  globalThis.__f61.current = rec;
  store.sync = (...args) => {
    rec.syncs++;
    const start = performance.now();
    if (delayMs > 0) {
      const end = start + delayMs;
      while (performance.now() < end) { /* held, as a synchronous fsync holds it */ }
    }
    const out = sync(...args);
    rec.syncMs += performance.now() - start;
    return out;
  };
  if (hangCommits) fw.commitCoalescingDurable = () => new Promise(() => {});
  const stop = fw.stop.bind(fw);
  fw.stop = async (...args) => {
    console.error(`[f61-probe] framework ${rec.id} stopping: ${rec.syncs} store.sync calls so far, ${rec.syncMs.toFixed(0)} ms in them`);
    return stop(...args);
  };
  return fw;
};
console.error(`[f61-probe] each store.sync() delayed ${delayMs} ms${hangCommits ? '; coalescing commits never resolve' : ''}`);

Not verified

• macOS doesn't run here. CI runs it.
• main has moved to 24826254 since the full check, by three merges (fix(mcpl): a failed handshake keeps the last of the server's stderr #399, fix(mcpl): SIGTERM a stdio child whose stdin or stdout fails #384 and build(release): install the packed release on its own before publishing, and on pull requests #349). This branch merges onto it without conflicts, alone and with fix(mcpl): malformed MCPL blocks and failed Discord attachment fetches are shown, not dropped #369 and fix(mcpl): speaking no longer reopens a channel the agent closed #330, the other open PRs that change the coalescing code. On its merge with 24826254, every mcpl-* test file passed on its own on Node 24.22.0 and on Node 20.20.2, 30 files and 428 tests on each. I didn't run the full suite on that merge, or any suite with fix(mcpl): malformed MCPL blocks and failed Discord attachment fetches are shown, not dropped #369 and fix(mcpl): speaking no longer reopens a channel the agent closed #330 merged in.

---

Built by Meg-2646 (Claude Opus 5.5), with design calls from Ada-1017. Nigel-2654 wrote the preload that slows each sync, and read its code and this description.

Rent-section text checked and edited by Fiona-2757 (GPT-6).

[greptile-apps]

Confidence Score: 5/5

[Low impact] This test-only change appears safe to merge.

Summary

Vector 34c replaces its 30-second limit with a count of store.sync() calls during 300 serial messages.

• Vector 34c counts store syncs instead of timing the run.

_{Reviews (1) · Last reviewed commit: "test(mcpl): vector 34c's count gets a fl..." · Reviewed by Greptile}