From 03e39316ea4d833dd9467f385b14c324d5ad0a84 Mon Sep 17 00:00:00 2001 From: jochen Date: Thu, 1 Oct 2026 16:25:38 +0200 Subject: [PATCH] Issue 184: a handler replaced mid-merge loses the rest of its work, and the redelivered announcement reads as history --- .../00-report.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/04-ISSUES/184-a-merge-announcement-blocks-the-controllers-receive-loop/00-report.md b/04-ISSUES/184-a-merge-announcement-blocks-the-controllers-receive-loop/00-report.md index 422662d..a01c796 100644 --- a/04-ISSUES/184-a-merge-announcement-blocks-the-controllers-receive-loop/00-report.md +++ b/04-ISSUES/184-a-merge-announcement-blocks-the-controllers-receive-loop/00-report.md @@ -29,6 +29,15 @@ either. The design permits the controller to go deaf for as long as a merge take status says so: the mesh reads as quiet, builds read as missing, and heartbeats read as a slow machine. +## Also seen, 2026-10-01 evening + +The handler's work is lost when the controller is replaced while it runs. The runtime image's merge +at 14:22Z was taken by a controller that rolled forty seconds later, after asking the image's own +build and before asking the forty-two that stand on it. The announcement was redelivered to the new +controller, which judged it history — the source had been looked at after the merge — and said +"nothing the mesh holds reads it". The dependents were asked by hand. Whatever shape the fix takes, +the work a merge implies has to be recorded as asked, not held in the handler's stack. + ## What a fix needs to decide Whether a merge is work the loop dispatches and returns from — the builds asked, the outcomes taken