docs(hot-reload): honest settle semantics and TTL comment

Micro-fixes from re-review, all text/bound-level, no behavior change to
production logic:

1. settleToBaseline's doc comment (config_hot_reload_test.go) claimed to
   guard the propagation window unconditionally. Reworded: it is a real
   guard on the fired path (two known rebuilds to wait out), best effort
   only on the skip path, where no amount of polling can prove a rebuild
   will never eventually fire — waiting is still required there because
   the earlier disappear-only check was a guaranteed-zero-wait bug, not
   because settling can prove safety on that path.
2. Restored the cleanup settle bound from 20s to 30s, matching the
   longest propagation delay actually observed during verification.
3. README's Config hot-reload intro dropped "on every run" and now
   states the same fired-vs-skip distinction the test's own Skip message
   makes: zero non-200s is blip-free-reload evidence only when the watch
   fires within the test's bound; otherwise it shows just that the stack
   survived an unreloaded rewrite attempt.
4. auth.go's group.cacheTTL field comment still said a positive value
   "overrides it for this group's cache entries only" — reworded to the
   corrected write-time/shared semantics: it sets the TTL written when
   that group's own request populates an entry, entries are shared
   across groups, not scoped by group.

Gate: go build/vet/gofmt clean on both modules; go test ./... -count=1
green.
This commit is contained in:
2026-08-21 00:04:27 +01:00
parent c1bb9fe87a
commit 611e9c04bc
3 changed files with 37 additions and 22 deletions
+8 -4
View File
@@ -37,10 +37,14 @@ type group struct {
agents []string
// cacheTTL is GroupConfig.CacheTTL parsed and validated at construction
// (newAuthStore below): 0 inherits the global responseCache's TTL
// (effectiveTTL, cache.go), a positive value overrides it for this
// group's cache entries only. GroupConfig.CacheTTL == "" is the only
// input that produces 0 here — every other value either becomes a
// positive duration or fails newAuthStore as a constructor error.
// (effectiveTTL, cache.go); a positive value sets the TTL written
// when THIS group's own request populates a cache entry. It is not a
// per-group scope — cache entries are shared across every group that
// can reach the model (groupCacheEnabled, cache.go), so a positive
// cacheTTL only ever controls a write's TTL, never which group can
// later read the entry. GroupConfig.CacheTTL == "" is the only input
// that produces 0 here — every other value either becomes a positive
// duration or fails newAuthStore as a constructor error.
cacheTTL time.Duration
}