• Joined on 2026-03-08
ltms commented on issue fleet/fleetd#333 2026-09-04 10:44:30 +02:00
fleet: is a third split key, sitting in the coverage checker's own escape hatch — and SPLIT_KEYS membership does not prove any reporting code exists

Merged to main as b4f9d7f (--no-ff; the branch was behind main). Follow-up commit eee4d57 fixes a doc gap the worker found and correctly left alone.

Build after the merge, unpiped: `Tests…

ltms opened issue fleet/fleetd#337 2026-09-04 10:44:09 +02:00
The deferred key set still has no reporting coverage — measured, a dropped comparison is invisible
ltms pushed to main at fleet/fleetd 2026-09-04 10:43:44 +02:00
eee4d576a2 #333: the Cold doc bullet listed four keys, COLD_KEYS has five
b4f9d7f53a Merge #333: fleet: is a split key, and split membership now proves a reporting branch exists
3aca53b967 fleetd#333: fleet.leaders is split too, and split membership now proves reporting exists
Compare 3 commits »
ltms closed pull request fleet/fleetd#332 2026-09-04 10:35:29 +02:00
fleetd#329: fix silent async-ticket bugs in MessageService (F1/F2/F3)
ltms closed issue fleet/fleetd#329 2026-09-04 10:35:24 +02:00
sendAsync's executor catch swallows every exception thrown after the future completes, and that is why a stranded async ticket is invisible
ltms opened issue fleet/fleetd#335 2026-09-04 10:35:17 +02:00
MessageService: three more places a thrown exception has nowhere to go
ltms commented on issue fleet/fleetd#329 2026-09-04 10:34:20 +02:00
sendAsync's executor catch swallows every exception thrown after the future completes, and that is why a stranded async ticket is invisible

Merged to main as 0c86503 (--no-ff; the branch was behind main, caught with git merge-base --is-ancestor). Follow-up commit 4aa1fae corrects a comment — see below.

Build after the…

ltms pushed to main at fleet/fleetd 2026-09-04 10:34:01 +02:00
4aa1fae296 #329: a null task in answer() is not only "never an async ticket"
0c865032f9 Merge #329: log an exception thrown after a ticket resolves, complete the ticket from the task answer() already holds, and read orphan.turnId once
ea41bbf6b9 fleetd#329: fix silent async-ticket bugs in MessageService (F1/F2/F3)
Compare 3 commits »
ltms opened issue fleet/fleetd#334 2026-09-04 10:33:46 +02:00
MessageService: an async ticket is still stranded between clearAsyncQuestion and closeAsk
ltms opened issue fleet/fleetd#333 2026-09-04 10:23:45 +02:00
fleet: is a third split key, sitting in the coverage checker's own escape hatch — and SPLIT_KEYS membership does not prove any reporting code exists
ltms closed pull request fleet/fleetd#331 2026-09-04 10:22:55 +02:00
fleetd#330: split reload class for health/coordinator + top-level coverage
ltms closed issue fleet/fleetd#330 2026-09-04 10:22:50 +02:00
health: and coordinator: are split keys — add a fourth reload class that says so, then make the top-level list prove its own coverage
ltms commented on issue fleet/fleetd#330 2026-09-04 10:22:44 +02:00
health: and coordinator: are split keys — add a fourth reload class that says so, then make the top-level list prove its own coverage

Merged as 7b918c5 (PR #331). Verified by me.

Full build after the merge, unpiped:

Tests run: 1348, Failures: 0, Errors: 0, Skipped: 0
BUILD SUCCESS

FleetConfig top-level coverage — 22…
ltms pushed to main at fleet/fleetd 2026-09-04 10:22:15 +02:00
7b918c51ff Merge #330: a fourth reload class for split keys, and a top-level coverage checker
554395b104 fleetd#330: split reload class for health/coordinator + top-level coverage
Compare 2 commits »
ltms opened issue fleet/fleetd#330 2026-09-04 10:02:12 +02:00
health: and coordinator: are split keys — add a fourth reload class that says so, then make the top-level list prove its own coverage
ltms opened issue fleet/fleetd#329 2026-09-04 10:00:04 +02:00
sendAsync's executor catch swallows every exception thrown after the future completes, and that is why a stranded async ticket is invisible
ltms closed pull request fleet/fleetd#328 2026-09-04 09:59:07 +02:00
fleetd#326: classify primary and configReload as deferred top-level keys
ltms commented on issue fleet/fleetd#326 2026-09-04 09:59:01 +02:00
The top-level deferred-key list has the same drift as #323, and two keys are read both from the startup snapshot and live — no single classification is right for them

Correcting myself on one point in the comment above. I presented the memberCredentials / memberLoginShell verdict as something I went and found. It was already written in this ticket's own…

ltms closed issue fleet/fleetd#326 2026-09-04 09:58:49 +02:00
The top-level deferred-key list has the same drift as #323, and two keys are read both from the startup snapshot and live — no single classification is right for them
ltms commented on issue fleet/fleetd#326 2026-09-04 09:58:44 +02:00
The top-level deferred-key list has the same drift as #323, and two keys are read both from the startup snapshot and live — no single classification is right for them

Merged as 2fd4a9e..823976c (PR #328), with one correction of my own.

What I checked myself

Branch was behind main, so --no-ff merge and a rebuild. Full build, unpiped:

Tests…