caddy-ratelimit

Simplified it, generics was over kill but I had a hard time understanding what a proper solution would be without the atomic pointer. Apologies for my AI slop.

With #85 ratelimit exposes metrics until a live reload happens! After that, ratelimit metrics aren't exposed anymore! Caddy supports live config reloads: when the Caddyfile changes (e.g. because a Kubernetes ConfigMap mount is updated after a helm upgrade), Caddy calls Provision() on all handlers again without restarting the process. On each reload, Caddy internally creates a new Prometheus registry (Registry-2). The admin /metrics endpoint switches to serve this new registry. All modules are expected to re-register their metrics against it. caddy-ratelimit does this in registerMetrics(): What happens next: globalMetrics still points to the collector objects registered with Registry-1 When a request is rate-limited, globalMetrics.declinedRequests.Inc() increments counters in Registry-1 /metrics serves Registry-2 — which has no increments Result: all caddy_rate_limit_* metrics appear stuck at 0 after any config reload Fix: globalMetrics must be updated on every Provision() call, not only when it is nil: This is safe because Provision() is called exactly once per reload and the newly created collector objects are already registered with the new registry at that point.

Fixes #100: metrics stop updating after a config reload (e.g. a ConfigMap remount after ). What's going on Caddy makes a fresh prometheus registry on every reload and points at the new one. only set the singleton while it was nil, so after a reload it kept pointing at the old registry's collectors. Increments went there while served the new (empty) one — so the series read 0. The fix Register collectors against the registry passed to each , and store them in an so the active collectors always match the registry is serving. Keep the one useful thing the nil check did — avoiding double-registration when multiple handlers share a registry — by reusing instead of dropping the new collectors. The atomic pointer also closes the data race raised in the issue: reads the singleton from request goroutines while a reload writes it, and the new config is provisioned before the old one stops, so live requests overlap the write. Tests — post-reload increments land in the new registry (fails on the old code). — concurrent reloads vs. request reads, clean under . passes.