Pure policy for the state where a segment's store is fenced while the control plane still calls it active: the range is closed to writes and nothing reconciles the two halves.

Malachi.BrokerServer's split and merge path closes the segment on the primary and only then records the seal through the control plane. Those two steps cannot be made atomic, and that is not an oversight: a fence has no inverse, which is the argument the whole fence design rests on, so a failed metadata write cannot be answered by unsealing the store. On a generic error from the second step (an ra timeout is the ordinary way to get one) Malachi.Broker.record_seal/5 returns the broker unchanged, so no roll is owed and nothing retries.

What that leaves is a produce loop with no exit: ensure_segment/2 finds no cached segment, adopts the one the metadata still calls active, the store refuses the batch with {:error, {:sealed, N}}, the cache is dropped, and the next produce adopts the same segment again. A successor is never opened. Nothing else rescues it either: Malachi.Cluster.Failover takes a segment only when its primary is dead, a copy failed, or its live replicas fall below the acknowledgement quorum, and here the primary is alive, healthy and among enough replicas, while healing and retention only touch sealed segments.

So this is the level-triggered half. candidates/2 names the segments to ask about, the caller asks each primary which of them are already fenced, and plan/3 turns those answers into seal commands. Level-triggered rather than a retry at the source, because a retry only converges while the process that owed the seal is alive: Malachi.BrokerServer seeds offsets and sequence floors on restart, not rolls, so a restart loses the debt for good.

Why no seal quorum here

Malachi.Cluster.Failover seals only once its seal quorum answered, and it has to: its primary may be dead, so the committed end is only knowable from the answers every acknowledgement quorum shares a replica with. Here the primary is ALIVE and its store is fenced, and the end it reports is the very number the fencing node itself would have recorded had its metadata write landed. The fence is a latch, so nothing can extend the segment past it. That is the same rule, from the same source, and it needs no new argument.

Why the pass may not fence

The probing this policy drives must not seal or fence, which is why it asks Malachi.Cluster.ReplicationServer.fenced_segments/3 (which reports a latch) rather than seal/4 (which sets one). That probe can still latch a copy whose log fails to open, except for a failure that may clear by the next request, which is refused and reopened on the next request; see its moduledoc. Malachi.Cluster.HealCoordinator learned this the hard way on the failover path: a pass that fenced while probing closed replicas of segments it then declined to seal, and at replication_factor: 2 that wedged a range permanently, because below a majority nothing was sealed and nothing unseals a store. This pass visits EVERY active segment, so the same mistake here would be that one multiplied by the whole workload.

Why it acts on the first observation

A segment can be legitimately fenced and not yet sealed for a moment, during a normal split or merge. Acting inside that window is harmless, and deliberately so rather than by luck. The fence is a latch, so the end this pass reads is the end the splitting node read; and when the splitter's own record_seal/5 then lands it is answered {:error, {:already_sealed, existing}}, which Malachi.Broker converges on and reports as :ok. Both sides agree on the same length and the split proceeds. Waiting for a second observation would buy nothing and would cost the coordinator a piece of per-segment state that a leadership change resets anyway.