test(router-proxy): pin the metrics endpoint to the llmkube registry - #1480
Merged
Defilan merged 1 commit intoAug 10, 2026
Merged
Conversation
The endpoint served the Prometheus default registry while every llmkube collector registers into controller-runtime's, so it exposed none of the series it exists for. That shipped in defilantech#1457 and was fixed in defilantech#1393; nothing stops it regressing again. The failure is silent, which is the reason it needs a test rather than care. The scrape returns HTTP 200 with Go runtime and process metrics, the PodMonitor from defilantech#1473 reports a healthy target, and the dashboards are simply empty. Touching a real counter before scraping is load-bearing: a labelled collector emits no family until it has a child series, so an idle scrape is identical under either registry and the obvious version of this test passes on the bug. Verified by reintroducing promhttp.Handler() and confirming the test fails, rather than assuming a new test must catch something. newMetricsHandler() is extracted from main() only so there is something to assert against. Co-authored-by: Sylvain Niles <540991+sylvainsf@users.noreply.github.com> Signed-off-by: Christopher Maher <chris@mahercode.io>
Defilan
force-pushed
the
fix/router-proxy-metrics-registry
branch
from
August 10, 2026 00:10
e08f42a to
276b000
Compare
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
A regression test pinning the router-proxy metrics endpoint to the registry the
llmkube collectors actually register into, plus the small extraction that makes
it testable.
Why
Refs #1427
The fix this PR originally carried is already on main. #1393 landed it while
this was open, so all that remains, and the part that was missing, is a test.
The endpoint added in #1457 wired
promhttp.Handler(), which servesprometheus.DefaultGatherer, whileinternal/metricsregisters every collectorinto
ctrlmetrics.Registry. Different registries, so it exposed none ofllmkube_router_*orllmkube_modelpool_*.That is worth a test rather than care, because the failure is silent in every
direction: the scrape returns HTTP 200, the PodMonitor from #1473 reports a
healthy target, and the dashboards are just empty. It survived review and a
merge for exactly that reason. Measured on the built binaries at the time: 38
metric families under the default registry, 149 under controller-runtime's.
How
One detail is load-bearing. The test increments a real router counter before
scraping, because a labelled collector emits no family until it has a child
series, so an idle scrape is byte-identical under either registry and the
obvious version of this test passes on the bug.
I verified that by reintroducing
promhttp.Handler()and confirming the testfails, then restoring the fix and confirming it passes. A regression test nobody
has watched fail is not yet a regression test.
newMetricsHandler()is extracted frommain()only so there is something toassert against; the behaviour is unchanged from what #1393 landed.
Credit
The underlying bug was found by @sylvainsf while rebasing #1393. This PR was
opened to carry the fix separately, and has been repurposed to the test now that
their fix has merged.
Testing
go test ./cmd/router-proxy/,make lint0 issues, and the fails-without-the-fixcheck described above.
Checklist
make testpasses locallymake lintpasses locallygit commit -s) per DCOAssisted-by: Claude Code (wrote the test and the extraction, and ran the
two-binary comparison and the fails-without-the-fix validation)