Skip to content

Tell a scheduler when the next slice is actually takeable - #164

Merged
ralyodio merged 1 commit into
mainfrom
fix-next-window
Aug 29, 2026
Merged

Tell a scheduler when the next slice is actually takeable#164
ralyodio merged 1 commit into
mainfrom
fix-next-window

Conversation

@ralyodio

Copy link
Copy Markdown
Contributor

Follow-up to #163, caught while verifying the live deploy.

The manifest advertised nextWindowOpensAt as windowEnd(latestClosedWindow()) — which is the same value as latestWindowEnd on the line directly above it, and an instant that has already passed. It is the boundary that closed the window being served.

Live right now, before this fix:

"latestClosedWindow":  "2026-08-29T12:00:00.000Z",
"latestWindowEnd":     "2026-08-29T16:00:00.000Z",
"nextWindowOpensAt":   "2026-08-29T16:00:00.000Z"   // already past; wrong instant

A buyer's scheduler keying on that field wakes at 16:00, re-pulls the identical 12:00 slice, and spins until the real boundary arrives. The window starting at 16:00 is the one still filling, so there is nothing new to take until it closes — one window further on, at 20:00.

Renamed to nextWindowAvailableAt while the field is a day old and nobody is depending on it yet. "When a window opens" is not a fact any caller needs; it just happens to read like the answer to the question they were asking.

The test asserts the property rather than a fixed timestamp — the served window's own end is in the past, the next slice's is in the future — checked at five offsets across a window, so it fails for any now and cannot be satisfied by the value it replaced.

Full suite green on Node 22, pnpm build clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Pij2tFcRgqceMpheotFSoX

The manifest advertised `nextWindowOpensAt` as `windowEnd(latestClosedWindow())`
— the same value as `latestWindowEnd` on the line above it, and an instant that
has already passed. It is the boundary that *closed* the window being served.

A buyer's pipeline keying on it would wake immediately, re-pull the slice it
already had, and spin until the real boundary arrived. The window starting at
that moment is the one still filling, so there is nothing new to take until it
closes, one window further on.

Renamed to `nextWindowAvailableAt` while it is a day old and nobody is reading
it yet: the old name described when a window opens, which is not a fact anyone
needs, and reads as the answer to the question they were actually asking.

The test asserts the property rather than a fixed string — the served window's
own end is in the past, the next slice's is in the future — so it fails for any
`now` and cannot be satisfied by the value it replaced.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Pij2tFcRgqceMpheotFSoX
@ralyodio
ralyodio merged commit 29d83c6 into main Aug 29, 2026
3 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