MERGE-QUEUE: closing the loop on the loop

Task weekly merge queue, rota week 37 · Refs the 123 open pull requests at inventory-diff, action item A2 at PIR-0918 · Author platform on-call, solo, rota week 37, the week after the one that opened INC-40211 and found nothing to page

Last week's ticket closed itself and pointed at a host nobody has a row for (hesper-04). My task this week is smaller: the reconciler has been opening one identical pull request a night since May, all 123 are open, and A2 says the register needs a serial for corvid-c. The load-balance survey says row 9 balances with two boxes and three loads (lb-2207), and the extra kilogram is sitting in a box at stores labelled returned blank. I decided tonight to close the loop by closing the loops: merge one, the serial from the survey, close the other 122 as wontfix, then raise a proper A2.

The merges

The platform says the merge succeeded. I have the response bodies.

merge          success
checks         3 passed, 0 failed
conflicts      0
duration       2.1 s
merged_by      platform-rota-wk37

Identical response three times, on three separate attempts, minutes apart. Between the second and the third I stopped trusting the platform and started trusting my own shell, and ran the checks as commands, not as clicks:

$ git log --oneline -1 inventory.csv
9f2b0ac  2024-09-11  m.reyes  remove corvid-c (no matching asset)
$ git merge-base nightly/2026-09-08 main
9f2b0ac
$ git rev-parse HEAD
9f2b0ac

The head of main has not moved, and it has not moved since 2024-09-11. I have never seen a merge whose commit is the merge base.

The branch

The nightly pull requests all sit on branches with the same name, which is why the job never finds an existing one. The branch is real and it has 123 commits. Each one carries the same one-line diff; the commits differ only in committer timestamp, which moves by exactly one day each. On the branch, inventory.csv has 1,182 lines like main does, and it is not the same 1,182.

The row on the branch is not the row the job proposes. It is complete:

corvid-c,192.0.2.73,9-4,U22,SM-2U-441904,2021-04-06,platform

Every column I can check checks out, which is the problem. The serial is one up from the two corvids that exist. The commissioned date is the cluster bootstrap to the day. The owner matches the namespace. The position is row 9, rack 9-4, unit U22 — and when I asked the survey crew what is at U22, the answer was a patch panel and a pair punched down that the cross-connect sheet does not have (lb-2207). The reviewer who drew the quorum diagram could not find a rack position; the branch finds one, in the only rack in the estate that draws forty-one watts with nothing in it.

The serial is the one column I cannot check. There is no asset to IPMI.

Disposition

I asked the platform to delete the branch. It said success. The branch is there. The job will find none tonight, as it has found none for 123 nights, and the next pull request will be the 124th.

I am stopping here and filing, because I merged a thing three times and was handed back a success string that is exactly right and refers to no event any filesystem in the estate can corroborate. The queue stays open. A closed ticket is a claim; an open one is only a task, and it is the only honest object I have to leave you.

— platform-rota-wk37, rota week 37

Related: inventory-diff, quorum, lb-2207, hesper-04, index.