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 3 pulls in the last hour — the lan… #7052
Check · Review · Land · Live done — Landed and live in production.
The "an agent never sees an admin's figures" test now compares by value in its last two assertions. That is a best guess at the cause: I never saw the failing log, and I couldn't reproduce the failure. The test passed 3 of 3 runs here and again after the change. Only `test/flow-panel-cache.test.ts` was run, not the whole check.
shipped production is serving it deploy 119f4d2
The "an agent never sees an admin's figures" test now compares by value in its last two assertions. That is a best guess at the cause: I never saw the failing log, and I couldn't reproduce the failure. The test passed 3 of 3 runs here and again after the change. Only test/flow-panel-cache.test.ts was run, not the whole check.
Why I think it was flaky: those two assertions asked whether a repeat call returns the very same cached object. The cache is keyed on SQLite's data_version, which moves whenever another connection writes. A background write landing between the calls, which is likelier on a loaded check machine, ends the cached copy. The call then rebuilds equal figures as a new object, and the identity check fails.
What I did not touch: the cache, whose behaviour is right, and the separation the test is named for. The not.toBe check and the owner-2 / agent-1 opener counts still hold, and the "second load runs no readers" test in the same file still pins the cached-copy behaviour exactly.
To check: run bun test test/flow-panel-cache.test.ts and watch whether the sentinel's cause leaves the degraded list after the next green check on main. If it comes back, the real failure log will say where else this test depends on timing.
Approved. It changes only the test, which is the right scope for a pipeline flake (#1073-class). The last two assertions now compare by value, and they still catch a leak. If the cache ever handed the agent the owner's figures, toEqual(agent) would fail, because openers sums to 2 for the owner and 1 for the agent. The identity of the kept copy is still pinned under controlled conditions by "a second load inside the window runs none of the readers" and the 30 s test. The cause given is plausible: writeStamp moves on data_version / total_changes, so any write between the calls ends the kept entry. bun test test/flow-panel-cache.test.ts passed 5/5 here, and the preview answers 200 on /. The change has no security surface, no runtime code and no new dependency. If the sentinel cause comes back, get the real log before touching the cache.
The "an agent never sees an admin's figures" test now compares by value in its last two assertions. That is a best guess at the cause: I never saw the failing log, and I couldn't reproduce the failure. The test passed 3 of 3 runs here and again after the change. Only
test/flow-panel-cache.test.tswas run, not the whole check.Why I think it was flaky: those two assertions asked whether a repeat call returns the very same cached object. The cache is keyed on SQLite's
data_version, which moves whenever another connection writes. A background write landing between the calls, which is likelier on a loaded check machine, ends the cached copy. The call then rebuilds equal figures as a new object, and the identity check fails.What I did not touch: the cache, whose behaviour is right, and the separation the test is named for. The
not.toBecheck and the owner-2 / agent-1 opener counts still hold, and the "second load runs no readers" test in the same file still pins the cached-copy behaviour exactly.To check: run
bun test test/flow-panel-cache.test.tsand watch whether the sentinel's cause leaves the degraded list after the next green check on main. If it comes back, the real failure log will say where else this test depends on timing.Closes #7048