Public: anyone can read this; the crew can change it.

Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:2tt6qpm3j9 is past its budget: trevato/forge: "flow panel cache > an agent never sees an admin's figures" failed on 4 pulls in the last hour — the lan… #7038

Merged opened this

Check · Review · Land · Live done — Landed and live in production.

Merged

This fixes the flaky "an agent never sees an admin's figures" test in `test/flow-panel-cache.test.ts`. `bun test test/flow-panel-cache.test.ts` passes (5 tests). I haven't seen the forge's check on the push yet, and I didn't reproduce the failure itself.

shipped production is serving it deploy 9b645c6

opened this

This fixes the flaky "an agent never sees an admin's figures" test in test/flow-panel-cache.test.ts. bun test test/flow-panel-cache.test.ts passes (5 tests). I haven't seen the forge's check on the push yet, and I didn't reproduce the failure itself.

Cause: the test inserted its two pulls with created_at set to exactly one hour before Date.now(). It then read the panel with a later new Date(). The openers reader only counts pulls in the hour before now, so any delay of a millisecond or more between those two calls pushed the pulls out of the window. Counts of 0 instead of 2 and 1 were then possible. A slow or loaded check machine makes that delay likely, which fits it failing on only some pulls.

Change: the test now creates the pulls 30 minutes ago, well inside the window, so its result no longer depends on how long the machine takes between those two calls. Only the test changed; src/ is untouched.

What I left out: I didn't audit the other tests for the same pattern of data placed exactly on a time boundary.

To try it: run bun test test/flow-panel-cache.test.ts.

Closes #7030

commented

This fixes the flaky "an agent never sees an admin's figures" test in test/flow-panel-cache.test.ts. bun test test/flow-panel-cache.test.ts passes (5 tests). I haven't seen the forge's check on the push yet, and I didn't reproduce the failure itself.

Cause: the test inserted its two pulls with created_at set to exactly one hour before Date.now(). It then read the panel with a later new Date(). The openers reader only counts pulls in the hour before now, so any delay of a millisecond or more between those two calls pushed the pulls out of the window. Counts of 0 instead of 2 and 1 were then possible. A slow or loaded check machine makes that delay likely, which fits it failing on only some pulls.

Change: the test now creates the pulls 30 minutes ago, well inside the window, so its result no longer depends on how long the machine takes between those two calls. Only the test changed; src/ is untouched.

What I left out: I didn't audit the other tests for the same pattern of data placed exactly on a time boundary.

To try it: run bun test test/flow-panel-cache.test.ts.

Approved

Approved. The diagnosis holds: readOpeners (src/flow/openers.ts:31) counts created_at >= now-1h, and the test seeded pulls at exactly now-1h, so any ms between seeding and new Date() dropped them out of the window. 30 minutes ago is well inside it and keeps the owner=2 / agent=1 assertions meaningful. Test-only, one line, no src/ or UI change, so nothing for phone/keyboard/JS-off. Two things next: (1) sweep other flow tests for data seeded exactly on a window edge (HOUR_MS/DAY_MS boundaries in idle_pulls, throughput, review_latency); (2) pass the same t used for seeding (e.g. seed relative to a fixed t) so the test never reads the wall clock twice.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs