Reading a Recurrence Reopen

The recurrence bot reopens a closed incident issue and writes "Reopened — this fault is happening again." That sentence carries two claims, and they fail independently:

1. the fault was seen after the close — otherwise the reopen reverses a person's judgement on evidence that person already had;
2. the fault was seen recently — otherwise "again" is a statement about a counter, not about the system.

Only the first has a fix in flight (MeshWeaver.Plugins#2014: issue.ClosedAt is { } closedAt && incident.LastSeen > closedAt). The second is unwritten, and it is the one that mattered on 2026-09-17.

The wave, and its residue

Between 07:51:00Z and 07:53:59Z on 2026-09-17 the bot reopened a burst of closed core incident issues. It is filed twice — #4577 (~130 across a wider 07:45–07:55Z window, backlog 43 → 164) and #4610 (~51 in the narrow one, backlog 46 → 97).

🚨 Those are ONE burst measured at two times, not two waves — do not add them. #4577 was written at 08:54Z and #4610 at 15:37Z, and #4610's window sits inside #4577's; the backlog figures differ because re-closing had been going on in between. A third reading at ~17:30Z finds 102 open and 51 from the burst — which matches #4610's count exactly, by a different instrument (it counted updated_at inside 07:40–08:15Z; this counts reopened events). Reading the two tickets as ~181 issues of damage overstates it by roughly threefold.

Denominator, measured 2026-09-17T~17:30Z: of core's 102 open issues, 51 carry a reopened event inside that three-minute burst. Every one of the 51 was closed before 2026-09-17 — 50 by rbuergi, 1 by github-actions[bot] — so all 51 are in scope, and the rest of the wave has already been unwound by earlier sessions.

Eight further issues carry a 2026-09-17 reopen outside the burst (#2387 05:33, #4222 06:42, #4326 08:54, #3712 09:13, #1198 11:04, #1840 13:55, #1561 16:04, #1140 16:06). #1198 was reopened by a human, not the bot. None of the eight is part of the wave and none was touched.

The finding: the residue passes the first predicate, 51 out of 51

Taking, per issue, the bot's own Last seen: from the very comment it posted alongside the reopen, and the closed event that reopen reverted:

So the residue of this wave is already clean by Plugins#2014's rule, which is the only rule that authorises re-closing. Nothing here may be re-closed on the evidence available, and nothing was. That is not the same as saying the 51 are live.

The second axis: how old is the evidence?

Measuring the newest occurrence any comment on the issue reports, against the reopen instant:

The oldest is 37.4 days (#1112, #1135 — last seen 2026-08-10, reopened 2026-09-17). That is the dishonesty in the count, and no close predicate anybody has proposed reaches it: these faults were seen after their close, and then stopped.

The honest triple

Awaiting delivery is empty here by construction. The newest close in the population is 2026-09-08T21:04Z, while memex.systemorph.com runs afde4ea (2026-09-15 21:50Z) and memex.meshweaver.cloud runs c84c6c0 (2026-09-12 09:30Z). Every fix that closed a wave issue is in both running images by at least four days, so no wave issue can be excused as delivery lag. (Whether a given close carried a fix at all is a separate question, answered per issue below; the delivery argument only establishes that if there was one, it is running.) The genuine awaiting-delivery cases on 2026-09-17 are the two reopened outside the wave whose fixes merged on 2026-09-16, after both images: #4616 and #4464.

The three that are live

Each has an occurrence on 2026-09-17, reported from memex-portal-deployment-6c967c7c4c-* — the currently-running replica. 🚨 What each close actually asserted differs, and that decides what the recurrence means — so the three are listed with their closing verdict rather than lumped together:

These three are the wave's entire signal. Reading the reopen wave as noise loses them; reading it as 130 regressions buries them.

🚨 And "recurring against its own fix" is a claim to check per issue, not a property of the bucket. Only #1549's close carried a stated, deployed fix; #2765's close explicitly identified no code defect, and #2299's carried no verdict at all. A live occurrence is a live occurrence either way — but only one of these three is evidence that a fix failed.

The third predicate nobody has written: the close races the roll

🚨 15 of the 51 have their ONLY post-close evidence within 17 hours of the close, and nothing in the 8–37 days since:

#2152 (+0.0 d) · #3466 (+0.0 d) · #2171 (+0.1 d) · #2182 (+0.1 d) · #2679 (+0.1 d) · #3051 (+0.2 d) · #2444 (+0.3 d) · #1112 (+0.4 d) · #1135 (+0.4 d) · #1175 (+0.4 d) · #2233 (+0.5 d) · #3647 (+0.5 d) · #2153 (+0.6 d) · #2876 (+0.6 d) · #3126 (+0.7 d)

Measured: the gap, and the silence after it. Inferred, not measured: that these are the old replicas still emitting between the merge that closed the issue and the roll that delivered it — a fix closes its issue when it merges, while the pods keep running the previous image for hours. Confirming it needs a pod→image mapping the incident comments do not carry.

If that reading is right, the predicate is not "was it seen after the close" but "was it seen on an image that contains the fix" — and it would take these 15 out of the wave without weakening the rule for the three that are live. It also explains why Plugins#2014's predicate, which is correct, leaves a residue that still reads wrong: a close and a delivery are different events, and the reopen rule compares against the earlier one.

How to read one, until both predicates exist

• A reopen means "re-read the record". It does not mean a fix regressed (#1122 says so, and this wave is the measurement behind it).
• Read Last seen:, never the counter. Still occurring: 705 more since the last update is a comparison of accumulated totals; it stays positive forever once an issue is closed while its record keeps history. Three of the 51 say Last seen: 2026-09-17; the rest say August or early September, with the same headline.
• Compare it to three timestamps, in this order: the close (was it even after?), today (is it recent?), and the image the reporting pod was running (could the fix have been in it?).
• A burn-down or "zero issues" reading across 2026-09-17T07:51Z is comparing two different populations. Say which side of the wave a count was taken on.

Appendix — the 51, one row each

A negative age means the newest occurrence is NEWER than the reopen: the fault carried on after the bot reopened the issue.

Live — seen 2026-09-17 (3)

Recently live — quiet 5–7 days at the reopen (7)

Quiet 8–37 days at the reopen (41)

Method

Read-only over the GitHub REST API: /issues?state=open (paginated, pull_request filtered out), then per issue /issues/{n}/events for the close/reopen pair and /issues/{n}/comments for the bot's own Last seen:. Last seen is taken from the reopen comment for the first axis and from the newest comment of any kind for the second, so a fault that resumed after the reopen is counted as live. Running images read from /api/version on both portals. No issue in the wave was closed, reopened, commented on or labelled.

See also

• Reopening on Image Provenance — the third predicate this page's 15-of-51 finding points at, designed: the evidence chain, the one link still missing, and the fail-safe for an image that cannot be resolved

• Operating from the portal, not the cluster — where the pod and image facts come from

• Router Traffic Detection — a detector that had the opposite problem: it named the rule broken without naming who broke it