bootstrap: apply --web.max-requests - #441
Open
mrueg wants to merge 1 commit into
Open
Conversation
The flag was registered, parsed, validated and stored, and then nothing acted on it. An exporter that supplies Config.MetricsHandler got a --web.max-requests=40 default in its help output that limited nothing. Bound the metrics handler with it. Requests arriving while the limit is reached are answered with 503 rather than queued, so a scrape that cannot be served fails quickly instead of piling up behind the ones already running, which matches what promhttp does for the same setting. A limit of zero leaves the handler unwrapped, as the flag help says. The bound is applied to the metrics endpoint only. Routes registered by a MetricsHandlerFactory are not covered, because the flag describes parallel scrape requests, and a health endpoint should still answer while the metrics endpoint is saturated. --web.disable-exporter-metrics cannot be applied the same way: only the metrics handler knows which collectors it gathers, and bootstrap is given that handler already built. It is reported to a MetricsHandlerFactory as Bootstrap.DisableExporterMetrics, so say that in the flag help rather than leaving it looking like something bootstrap acts on. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Manuel Rüger <manuel@rueg.eu>
mrueg
force-pushed
the
fix/bootstrap-max-requests-inert
branch
from
September 2, 2026 13:44
ca97f74 to
e0d6023
Compare
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
1 participant
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.
--web.max-requestsis registered, parsed, validated and stored, and then nothing acts on it. An exporter that suppliesConfig.MetricsHandlergets a--web.max-requests=40default in its help output that limits nothing.Change
Bound the metrics handler with it. Requests arriving while the limit is reached are answered with 503 rather than queued, so a scrape that cannot be served fails quickly instead of piling up behind the ones already running — matching what
promhttpdoes for the same setting. A limit of 0 leaves the handler unwrapped, as the flag help says.The bound applies to the metrics endpoint only. Routes registered by a
MetricsHandlerFactoryare not covered, because the flag describes parallel scrape requests and a health endpoint should still answer while the metrics endpoint is saturated. There is a test for that.This deliberately does not pull in
client_golangas a direct dependency — the limiter is a few lines ofchan struct{}.--web.disable-exporter-metrics
This one cannot be applied the same way: only the metrics handler knows which collectors it gathers, and
bootstrapis given that handler already built. It is reported to aMetricsHandlerFactoryasBootstrap.DisableExporterMetrics, so this says that in the flag help rather than leaving it looking like somethingbootstrapacts on. Happy to take a different approach if you would rather it did something more.Tests
Three tests: the limit is enforced, 0 disables it, and other routes are unaffected. The first hangs against master, since without the bound the second request enters the handler instead of being turned away.
🤖 Generated with Claude Code