fleet/fleetd
3
0
Fork 0
Code Issues 73 Pull Requests Actions Packages Projects Releases 1 Wiki Activity

Features: correct the stale owner of the unpinned startup-report call site 

The 'usage-limit detection' entry said the six FleetConfig.validateXxx()
startup calls had the same unpinned shape and that fleetd #398 owned closing
it. Both halves were wrong.

- #398 is the closed models allow-list PR, not a ticket for this.
- The validateXxx half is FIXED: the six calls were collapsed into one
  cfg.validateAll(), pinned by FleetdStartupValidationTest calling the real
  Fleetd.main and asserting it refuses a bad config.

Also widened the gap statement. It is not only reportExhaustedPatternGap:
all four startup reports are referenced by exactly one test file each, and
each of those tests calls the method directly, so no test proves main still
calls any of them. fleetd #442 now owns it.
Dai Ha
2026-09-10 14:30:44 +07:00
parent 4a297bda8c
commit bdaef4000c
1 changed files with 8 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
11-Features.md
+8 -2
@@ -4858,8 +4858,14 @@ subscription is the thing that actually runs out.
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.
own behaviour is tested; that it is still *called* is not. This is true of all four startup
reports, not just this one — `reportGitHostShape`, `reportMemberTrustModel`,
`reportMemberCredentialsGap` and `reportExhaustedPatternGap` are each referenced by exactly one
test file, and that test calls the method directly. **fleetd #442 owns closing it.**
The six `FleetConfig.validateXxx()` startup calls had the same defect and it is now FIXED: they
were collapsed into one `cfg.validateAll()`, which `FleetdStartupValidationTest` pins by calling
the real `Fleetd.main` and asserting it refuses a bad config. (An earlier version of this line
said "fleetd #398 owns closing it". That was wrong: #398 is the closed models allow-list PR.)
**Two limits of the detection this reports on.** Both bound what any recovery feature can do, so
read them before designing one.