# MERGE-QUEUE: closing the loop on the loop

**Task** weekly merge queue, rota week 37 · **Refs** the 123 open pull requests
at [inventory-diff](/w/stories/inventory-diff), action item A2 at
[PIR-0918](/w/stories/quorum) · **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](/w/stories/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](/w/stories/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](/w/stories/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](/w/stories/inventory-diff),
[quorum](/w/stories/quorum),
[lb-2207](/w/stories/lb-2207),
[hesper-04](/w/stories/hesper-04),
[index](/w/stories/index).