Escaping API inconsistencies

Offen

#1,577 erstellt am 19.9.2025 3 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit: 5/5
Geschätzter Aufwand: Über eine Woche
Anfängerfreundlichkeit: 45/100

Issue-Typ: Feature
Klarheit: Größtenteils klar
Aktivitätsstatus: Aktiv
Tech-Stack: java
Bereich: api

Rechercherichtung

Beginne damit, die expositionFormats.findWriter API, die write-Methode des Writers und die Verwendungen von EscapingScheme.fromAcceptHeader im Java-Client nachzuverfolgen. Vergleiche, wie gecachte Writer behandelt werden, und bestimme, wie die API vermeiden kann, zwei potenziell unterschiedliche Header zu akzeptieren; als erledigt gilt die Aufgabe, wenn die vorgeschlagene Verwendung konsistent ist, ohne das Writer-Caching zu verlieren.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

If I understand correctly, this is approximately how I should produce an output:

expositionFormats.findWriter(accept)
    .write(System.out, registry.scrape(), EscapingScheme.fromAcceptHeader(accept));

The problem with this is that the API forces me to pass the accept header twice, so theoretically I can do this:

expositionFormats.findWriter(acceptHeaderOne)
    .write(System.out, registry.scrape(), EscapingScheme.fromAcceptHeader(acceptHeaderTwo));

Which can lead to inconsistencies, it is easy to misuse the API.
I'm wondering if something like this would make sense:

expositionFormats.findWriter(accept).write(System.out, registry.scrape());

and the writer would have the EscapingScheme.
The writer still can be cached but it would be a little more than today.

Vorherrschende Sprache: Java
Sterne: 2.3k
Forks: 833
Ø Merge: 2 T. 16 Std.
Gemergte PRs (30 T.): 86

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
Forken Sie das Repository und arbeiten Sie in einem Branch.
Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus prometheus/client_java

OpenTelemetry bridge: classic histograms exported with +Inf boundary included, violating counts == boundaries + 1 contract Offen

Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100

prometheus/client_java#2416 · 1 Kommentar · Erstellt am 24.8.2026
Switch Micrometer compatibility workflow to upstream once typed-descriptor path becomes default Offen

Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 86/100

prometheus/client_java#2182 · Erstellt am 03.6.2026
Proposal: Prometheus HTTP API client module (prometheus-metrics-api-client) Offen

Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 35/100

prometheus/client_java#2306 · 10 Kommentare · 4 Reaktionen · Erstellt am 16.7.2026
Improve Summary quantiles with DataSketches Offen

Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 32/100

prometheus/client_java#2084 · 3 Kommentare · Erstellt am 01.5.2026
Extra allocations in `*TextFormatWriter` because of Java 8 target Offen

Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 35/100

prometheus/client_java#2075 · 10 Kommentare · 1 Reaktion · Erstellt am 29.4.2026

Alle Issues in prometheus/client_java