From 3450e73e413168e2434c58131f71d1c65edf5552 Mon Sep 17 00:00:00 2001 From: Dai Ha Date: Fri, 4 Sep 2026 10:22:39 +0700 Subject: [PATCH] Features: stopping a member fails its ticket even mid-fleet_ask (#275) --- 11-Features.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/11-Features.md b/11-Features.md index 97ea5f3..69a6b6c 100644 --- a/11-Features.md +++ b/11-Features.md @@ -1174,6 +1174,22 @@ The flip side is the honest limitation: the new state is recorded *before* the b if all three attempts throw, the tickets stay pending and no later tick retries. That path logs at WARN and has its own test — it is a known edge, not an oversight. The retries also carry no backoff. +**Stopping a member also fails its ticket now, even mid-`fleet_ask` (fleetd #275).** There are two +ways a ticket loses its member, and they are not the same event. Health reporting `GONE` is a +**guess** read off the live agent list; `fleet_stop` or the idle reaper releasing a session is a +**teardown the daemon performed**, so it is certain. The sweep now takes a flag that says which one +it is. On a certain teardown it also fails a ticket parked in `fleet_ask` — the member is gone, so +nobody can ever answer that question — and closes the reverse rendezvous behind it. On a health +guess it still skips an asking ticket, because the member may be answerable by a live lead and a +guess must not kill it. + +**Gotcha for #275.** The health path is deliberately left unable to self-heal one narrow case: a +member goes `GONE` while its session stays in the roster, its `fleet_ask` then lapses on its own, +and nothing re-fires the sweep — the transition already fired once, and `FleetHealth.decide` +returns `GONE` before it could ever return `DELEGATION_ORPHANED`. That is filed as fleetd #280, and +whether it is reachable at all depends on whether such a session is eventually released anyway, +which has not been checked. + --- ## Tell a usage-limit refusal from a real reply