Features: startup reports which profiles have usage-limit detection off

2026-09-10 08:43:48 +07:00
parent 216191277c
commit 2a570c5c06
1 changed files with 35 additions and 0 deletions
@@ -4792,3 +4792,38 @@ most the counter can ever honestly claim.
  three `outcome` values (`resolved_send`, `resolved_async_ticket`, `queued`) are the stable names.

 fleetd #365.
+
+## Startup says which profiles have usage-limit detection turned off
+
+**What.** `exhaustedPattern` is the per-profile regex that recognises "you are out of quota" in a
+backend's own words. It is opt-in, and a profile without one has usage-limit detection off. Two
+places now say so:
+
+- **At startup** the daemon logs one aggregate `WARN` naming every profile with no
+  `exhaustedPattern`, plus a second, louder `WARN` if any of them is a subscription profile. When
+  every profile is armed it logs an `INFO` instead, so the healthy case is also on the record.
+- **In the API** `fleet_profiles` and `GET /profiles` carry `exhaustionDetectionArmed`, a boolean
+  per profile. A lead can read the state without shell access to the daemon's log.
+
+**The knob.** None to turn this on. The knob it reports on is `profiles.<name>.exhaustedPattern`;
+set one to arm detection for that profile.
+
+**Why it exists.** A missing `exhaustedPattern` failed in the worst way an opt-in can fail: nothing
+was wrong, nothing was logged, and the profile kept accepting spawns. When the credential really
+hit its limit, the backend said so in prose, fleetd did not recognise it, and no quarantine
+started — so the fleet kept spawning members onto a dead credential. The operator's only clue was
+members that spawn fine and produce nothing. A subscription profile is the sharp case, because a
+subscription is the thing that actually runs out.
+
+**Gotchas.**
+
+- **Armed is not correct.** `exhaustionDetectionArmed: true` means a pattern is configured, not
+  that it matches what this backend prints. A wrong pattern reports as armed.
+- **`errorPattern` has the same opt-in shape** and is not covered by this report. It is less
+  severe: with none set, the code falls back to a narrow built-in pattern rather than going inert.
+- **The startup call site is not pinned by a test.** Deleting `reportExhaustedPatternGap(cfg)` from
+  `Fleetd.java` leaves the suite green (measured at the merge: 1472 tests, 0 failures). The report's
+  own behaviour is tested; that it is still *called* is not. Same shape as the six
+  `FleetConfig.validateXxx()` startup calls — fleetd #398 owns closing it.
+
+fleetd #395.