From 803c91ea6c47b646770c75a3da555f247678c1c4 Mon Sep 17 00:00:00 2001 From: Dai Ha Date: Mon, 5 Oct 2026 05:37:32 +0200 Subject: [PATCH] fleetd #737 unit 3: name the resolving accessor in LeadRollover's javadoc The heartbeat loop now resolves its nudge target through PrimaryRegistry#currentPrimaryTerminal(), so the sentence describing what a background loop with no caller uses named the raw accessor instead. --- fleetd/src/main/java/dev/ltms/fleet/lead/LeadRollover.java | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fleetd/src/main/java/dev/ltms/fleet/lead/LeadRollover.java b/fleetd/src/main/java/dev/ltms/fleet/lead/LeadRollover.java index daeabdad..1a0dcf6a 100644 --- a/fleetd/src/main/java/dev/ltms/fleet/lead/LeadRollover.java +++ b/fleetd/src/main/java/dev/ltms/fleet/lead/LeadRollover.java @@ -93,7 +93,7 @@ import java.util.function.Supplier; * *

Identity is resolved by the caller, never looked up here — a second fleetd #480 * correction. The first version resolved the pane to clear via {@code - * PrimaryRegistry#primaryTerminal()}. That is correct for a background loop with no caller (see + * PrimaryRegistry#currentPrimaryTerminal()}. That is correct for a background loop with no caller (see * {@code dev.ltms.fleet.msg.LeadHeartbeatLoop}), but wrong here and a violation of this project's * own charter invariant 3 — "identity comes from the connection, never an argument." This daemon * can hold more than one labelled lead tab (see {@code LeadLauncher}'s fleetd #359 two-reading