Skip to content

the settlement window was never persisted, which is why the panel kept changing - #3238

Merged
Flotapponnier merged 1 commit into
devfrom
fix/settle-window-survives-deploy
Oct 23, 2026
Merged

Flotapponnier merged 1 commit into
devfrom
fix/settle-window-survives-deploy

Conversation

@Flotapponnier

Copy link
Copy Markdown
Collaborator

the settlement window was never persisted, which is why the panel kept changing

Florent kept asking why the settlement panel shows only FOMO. The answer was
not what any of us assumed, and finding it needed a real browser rather than
curl.

curl returns identical HTML for every chain, on this bench AND on an
untouched control, so the chain selector runs client side and curl is blind to
it. Driven in headless Brave the selector plainly works: all chains gives one
set of rows, chain=bnb another. What it also showed is that the ROWS CHANGE
between loads twenty minutes apart, FOMO and Phantom then pump.fun app and
FOMO, and that a rank can start at #2 with nothing at #1.

That is routes crossing the ten-sample publication floor and falling back
under it. pumpSettleWindow lives only in memory, so every deploy resets every
route's samples to zero and each has to climb the floor again. This bench was
deployed about eight times tonight, so the panel spent the evening showing
whichever routes happened to be above the line when the page materialised.

I persisted the pump deposit window hours ago for exactly this reason, then
the Mobula intents, then the Mobula fill cursors, writing in each commit that
the lesson was learned. The settle window is the FOURTH thing in this process
with the same property, it is the only one whose loss was visible on the page,
and I walked past it three times while the symptom was the thing being asked
about.

So it goes in State with the others: a serialisable mirror, since the window
is keyed by a struct that cannot marshal, and an hour's age limit on load so a
long outage cannot publish a mean about a period nobody can see any more.

Restoring the samples is not enough on its own. noteSettle only publishes for
the route it was called about, so loadSettleWindow republishes every restored
route's quantiles; without that the gauges would stay empty until each route
happened to settle again, which is the gap this exists to close. The test
asserts the figure is back with no new settlement arriving.

…t changing

Florent kept asking why the settlement panel shows only FOMO. The answer was
not what any of us assumed, and finding it needed a real browser rather than
curl.

curl returns identical HTML for every chain, on this bench AND on an
untouched control, so the chain selector runs client side and curl is blind to
it. Driven in headless Brave the selector plainly works: all chains gives one
set of rows, chain=bnb another. What it also showed is that the ROWS CHANGE
between loads twenty minutes apart, FOMO and Phantom then pump.fun app and
FOMO, and that a rank can start at #2 with nothing at #1.

That is routes crossing the ten-sample publication floor and falling back
under it. pumpSettleWindow lives only in memory, so every deploy resets every
route's samples to zero and each has to climb the floor again. This bench was
deployed about eight times tonight, so the panel spent the evening showing
whichever routes happened to be above the line when the page materialised.

I persisted the pump deposit window hours ago for exactly this reason, then
the Mobula intents, then the Mobula fill cursors, writing in each commit that
the lesson was learned. The settle window is the FOURTH thing in this process
with the same property, it is the only one whose loss was visible on the page,
and I walked past it three times while the symptom was the thing being asked
about.

So it goes in State with the others: a serialisable mirror, since the window
is keyed by a struct that cannot marshal, and an hour's age limit on load so a
long outage cannot publish a mean about a period nobody can see any more.

Restoring the samples is not enough on its own. noteSettle only publishes for
the route it was called about, so loadSettleWindow republishes every restored
route's quantiles; without that the gauges would stay empty until each route
happened to settle again, which is the gap this exists to close. The test
asserts the figure is back with no new settlement arriving.
@Flotapponnier
Flotapponnier merged commit b4c35d3 into dev Oct 23, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant