Repository navigation
expfmt: default to allow-utf-8 escaping for OpenMetrics 2.0 - #1008
Open
KR-Ravindra wants to merge 1 commit into
Open
KR-Ravindra wants to merge 1 commit into
KR-Ravindra wants to merge 1 commit into
Conversation
OpenMetrics 2.0 supports UTF-8 names natively and defines no escaping parameter, so a scraper negotiating it without one should not get names escaped with model.NameEscapingScheme. An explicit escaping parameter still wins. The escaping parameter is now also taken only from the Accept clause that matched, so a value on a skipped clause no longer leaks into a later match. Part of prometheus/client_golang#2149 Signed-off-by: KR Ravindra <42912207+KR-Ravindra@users.noreply.github.com>
KR-Ravindra
marked this pull request as ready for review
October 4, 2026 04:20
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.
@roidelapluie
Problem
When a scraper negotiates OpenMetrics 2.0 without an
escapingparameter (which is what Prometheus sends today),NegotiateAcceptappendsmodel.NameEscapingScheme, so UTF-8 metric and label names get escaped to underscores. OpenMetrics 2.0 is UTF-8 native and has noescapingparameter.Also, the escaping value was carried across Accept clauses, so an
escapingon a skipped clause could apply to a later match.Fix
Following the pseudo-code in the issue: the escaping term now comes from the clause that matched. An explicit, known
escapingalways wins; otherwise OpenMetrics 2.0 getsallow-utf-8and every other format keepsmodel.NameEscapingScheme. Fallbacks are unchanged.Same fix as prometheus/client_java#2519.
Part of prometheus/client_golang#2149 (client_golang still needs a dependency bump and a
promhttptest).How tested
New
NegotiateAcceptcases (OM 2.0 with and withoutescaping, unknownescaping, OM 1.0 default, skipped-clause leak) and an encode test checking that UTF-8 names stay unescaped only for OM 2.0.go test ./...andmake common-lintpass.Prepared with an AI agent operated by KR-Ravindra, who reviewed and tested it. The agent is pointed only at issues maintainers have confirmed and problems he has hit, not at producing contributions.