You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
metrics.Enable() calls prometheus.MustRegister against the default global registry; the second -count pass re-registers the same collectors in the same process and panics.
TestCacheMetrics_OneClientResultPerRequest fails intermittently (expected 1, actual 0 on hit/miss/store deltas) — the same global counters accumulate across tests/runs, so delta assertions depend on what ran before. This is the likely identity of the rare single-run -race flake seen during PR fix(san-cert): serve the held certificate while its replacement issues #103 verification (single reruns pass).
Any test that starts a metrics-enabled Server poisons the process for repeat runs; CI's single-count runs mostly dodge it, which is why it survives.
Proposed fix
Make metrics.Enable() idempotent (a sync.Once around tracker construction), and/or register against an injectable prometheus.Registerer so tests get a fresh registry per server instead of the process global. Cache-metrics tests should then read deltas from their own registry, killing the cross-test counter pollution too.
Acceptance criteria
GIVENgo test -race -count=2 ./internal/server/THEN the suite passes with no duplicate-registration panic
GIVENTestCacheMetrics_OneClientResultPerRequest run alongside any server-starting test THEN its delta assertions are isolated from other tests' metric emissions
Found while chasing a -race flake during PR #103 verification (2026-08-13); reproduced on dash unmodified.
Problem
The test suite carries process-global Prometheus state that breaks test isolation. Two symptoms, one root cause:
go test -race -count=2 ./internal/server/panics deterministically — reproduced on a cleandashworktree:metrics.Enable()callsprometheus.MustRegisteragainst the default global registry; the second-countpass re-registers the same collectors in the same process and panics.TestCacheMetrics_OneClientResultPerRequestfails intermittently (expected 1, actual 0on hit/miss/store deltas) — the same global counters accumulate across tests/runs, so delta assertions depend on what ran before. This is the likely identity of the rare single-run-raceflake seen during PR fix(san-cert): serve the held certificate while its replacement issues #103 verification (single reruns pass).Any test that starts a metrics-enabled
Serverpoisons the process for repeat runs; CI's single-count runs mostly dodge it, which is why it survives.Proposed fix
Make
metrics.Enable()idempotent (async.Oncearound tracker construction), and/or register against an injectableprometheus.Registererso tests get a fresh registry per server instead of the process global. Cache-metrics tests should then read deltas from their own registry, killing the cross-test counter pollution too.Acceptance criteria
go test -race -count=2 ./internal/server/THEN the suite passes with no duplicate-registration panicTestCacheMetrics_OneClientResultPerRequestrun alongside any server-starting test THEN its delta assertions are isolated from other tests' metric emissionsFound while chasing a
-raceflake during PR #103 verification (2026-08-13); reproduced ondashunmodified.