feat(anomaly): extend config-drift to encoding-threshold configs (valkey#3479)

[jamby77]

Summary

Extends the existing config-drift detector (valkey#1193) to the encoding-threshold configs from valkey-io/valkey#3479. When these diverge across a replication group, the same data silently re-encodes on the divergent node after an RDB reload, restore, or clone (e.g. listpack promoted to hashtable/skiplist), occupying far more memory than the source needed — upstream's "retain encodings during RDB reload" knob is unshipped, but the config divergence that triggers the bloat is observable today.

Per the issue's guardrails this is an extension, not a parallel detector: it reuses the per-node CONFIG snapshot, grouping, signature dedupe, and partial-fetch retention logic unchanged.

Changes

• New labeled subgroup ENCODING_THRESHOLD_CONFIG_DRIFT_KEYS (8 keys): hash-max-listpack-entries/-value, list-max-listpack-size, set-max-intset-entries, set-max-listpack-entries/-value, zset-max-listpack-entries/-value — kept separate from DEFAULT_CONFIG_DRIFT_KEYS so the advisory can explain the encoding-specific consequence.
• isEncodingThresholdKey() classifier; the service's drift advisory branches on it: encoding keys get the memory-re-encoding rationale (valkey#3479), everything else keeps the existing valkey#1193 reconcile message.
• The service now fetches and compares the combined list. Partial CONFIG fetches retain prior snapshot values exactly as before (merge logic untouched).

Test plan

• 5 new unit tests: divergence on an encoding key fires and names the key, matched thresholds stay silent, a node that failed to report a key is excluded rather than treated as drifted, classifier covers exactly the subgroup (and none of the default keys), and the subgroup spans all four collection types.
• Full anomaly-detection suite: 503/503 green; tsc --noEmit clean.

Closes #370

---

Note

Medium Risk
Changes cross-node config monitoring and alert copy; throttling could delay detection of newly changed keys for up to one recheck window, though replid changes bypass the cache.

Overview
Extends config drift detection with eight encoding-threshold keys (valkey#3479) and adds throttled CONFIG reads for the drift allowlist while keeping per-poll drift evaluation.

Encoding thresholds: New ENCODING_THRESHOLD_CONFIG_DRIFT_KEYS and isEncodingThresholdKey(); the anomaly service fetches and compares them alongside the existing default keys. Drift advisories for those keys use a dedicated message about silent re-encoding and memory bloat after RDB reload/restore/clone, instead of the generic valkey#1193 reconcile text.

Snapshot refresh: Config snapshot updates move into refreshConfigSnapshot() with a per-connection configDriftRecheck countdown (CONFIG_DRIFT_RECHECK_POLLS = 60) so the full allowlist is not CONFIG GET on every poll. Drift is still scanned every poll from cached snapshots; a replid change forces an immediate re-read. Connection teardown clears configDriftRecheck.

Tests: Unit coverage for encoding-threshold drift/classification; service tests for throttle behavior, peer mismatch on cached snapshot, failover replid bypass, and expireConfigRecheck for scenarios that need a fresh read within the recheck window.

^{Reviewed by Cursor Bugbot for commit d046591. Bugbot is set up for automated code reviews on this repo. Configure here.}

[jamby77]

@claude @cursoragent review

[jamby77]

@BugBot review

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit c6275f6. Configure here.}

[KIvanow]

this doubles the per-poll CONFIG GET volume (7→15 commands per connection, every poll) with no throttle — for config that basically never changes. Could fold it into a single multi-arg CONFIG GET a b c … (Valkey 7.0+), or add a slow-recheck countdown like the large-reply/COB threshold path already does. Won't that work?

[jamby77]

Good catch — throttled it rather than folding into a multi-arg CONFIG GET, since the recheck-countdown path already exists here (cobLimitRecheck / largeReplyThresholdRecheck) and works on any server version, whereas multi-arg CONFIG GET would need a 7.0+ capability check plus a per-key fallback for older nodes.

refreshConfigSnapshot now caches each connection's curated snapshot and re-reads it only every CONFIG_DRIFT_RECHECK_POLLS (60), so amortised cost is 15 CONFIG GETs per 60 polls — below the pre-PR baseline of 7 per poll.

Two things worth flagging:

• Drift is still evaluated every poll; only the fetch is throttled. A newly registered peer surfaces an existing mismatch on its first poll rather than waiting out someone else's window.
• A master_replid change forces an immediate re-read, so groupKey is never rewritten without a matching fresh config read — otherwise a failover could park a node in a new group for up to a window while serving cached config, which is exactly the re-fire the fetchedAny guard exists to prevent.

Three tests added for the new behaviour (window reuse, evaluation-while-throttled, replid-change refetch); the two existing tests that simulate observing a later config value now expire the countdown explicitly, since adjacent polls in a test stand in for reads minutes apart in the field.