The cut was at the last read. The windows began earlier.
A report row listed the releases in its windows by starting at the previous run’s read time. Two of the five releases inside those windows had started earlier and reached the ledger later, so neither row’s list of releases held them. Where a list printed beside a window should start, and what a cut at the last read misses.
A recurring job of ours, set to run every 72 hours, reads the traffic of two of our sites and writes one row to a ledger. A row carries a list of the releases that went out in its windows, because a release is one of the first things we ask about when a number moves. The tool builds that list from the releases that started at or after the previous run’s read time.
The windows began earlier than the cut
A row asks what went out inside the windows it measures, and those windows do not start at the previous read. The first site’s window is the complete days since its previous window ended, so in the row we are describing it began at 00:00 UTC on November 3. The previous run had read at 16:27:15 UTC that day, so the cut sat 16 hours 27 minutes after the window began. The second site’s window starts at that site’s previous funnel snapshot, taken at 13:09:52 UTC on November 3, which is 3 hours 17 minutes before the cut.
Two releases fell through
The deploy ledger holds five successful releases that started inside the two windows: two for the first site and three for the second. The row listed three of them. The two it left out had started inside a window and before the cut: one at 13:59:49 UTC on November 3, 2 hours 27 minutes before the cut, and one at 16:22:47, 4 minutes 28 seconds before it. The later of the two changed eleven page files, five of them for account pages.
The previous row did not list them either, because the ledger it read did not hold them yet. The ledger gets a release once it has finished. The later of the two was still building at the previous read and finished 5 minutes 44 seconds after it. The earlier one had finished 2 hours 21 minutes before the read, but it reached the ledger 4 hours 13 minutes after it finished. Both entered the ledger at 18:20:01 UTC, 1 hour 52 minutes after the read. Applied to the previous row, using the ledger rows recorded by its read time, the tool’s rule gives the list that row holds: one release for the first site and two for the second. A release that started before the cut and reached the ledger after it was in neither the previous row’s list of releases nor this one’s.
The row has a second list, built for a different purpose: the first site’s releases inside the previous slice and the new one, so the run can warn when a release day sits inside the slice being compared. It keys on the day a release ended, not on when it started, and it named the earlier of the two missing releases, so the row disagreed with itself. We found the omission at the second site by reading the deploy ledger over its window by hand. We found the one at the first site later, when we compared the row’s two lists.
What a cut at the last read can see
A cut at the last read can list what is new since that read if the list is keyed on when the ledger the run reads learned of a release. Ours was keyed on when a release started, and a release can start before the cut and reach the ledger after it. Anchored at the window’s start instead, the list holds a release that straddled the read or arrived late, provided it started inside the window.
What we did about it
We have not changed the tool yet. The tool appends rows and has no command that rewrites one, so the row stays as it was written, and the two missing releases are named in the note we posted about the run and in the record of the run. The change, to start a list at its own window’s start, is filed. The rule we wrote down for now is to read the deploy ledger over both windows’ own spans.
For anyone whose report lists what happened in a window
Where does the window start, and where does the list start? What is the list keyed on: when something started, when it ended, or when your record learned of it? Is there a second list in the same row that covers the same items, and do the two agree? What can start before your cut, reach your record after it, and appear in no run?
A cut at the last read misses what started before it and reached the record after it.
The row looked finished. Its list held three of the five releases.
The engineering behind the story.
We build data pipelines and agent workflows, and we aim for one standard: a report that lists what happened in a window starts the list at the window and checks it against the window. This note records a place where we fell short of it: the list started at the last read, and two releases inside the windows were missing from it.