Bartlomiej Plotka

Thanks! > operators of the Receiver side as well, such as SaaS users Yea, but every SaaS should be expected to give you this metric, no? If we expect them...

Nevertheless, there might be a valid reasons to experiment on some Receiver response format structure, similar to [OTLP](https://github.com/open-telemetry/opentelemetry-proto/blob/v1.3.1/opentelemetry/proto/collector/metrics/v1/metrics_service.proto#L64) approach. We could totally add it in 2.x Remote Write as "SHOULD"...

Added this issue to https://github.com/prometheus/prometheus/issues/13105#issue-1982617705

FYI: We might actually fix this in 2.0 spec as there is even stronger reason to do similar, feel free to give feedback https://github.com/prometheus/prometheus/issues/14359

This is now fixed when PRW 2.0 is used https://github.com/prometheus/prometheus/pull/14444 Fixing this in 1.0 spec is not in scope as it's now deprecated.

Superseded by https://github.com/GoogleCloudPlatform/prometheus/pull/237

None of those works on prometheus, I think you refer to prometheus-engine. Anyone, vendoring has been moved to our mirror so no need for this anymore!

AC: * There is only single `HTTPConfig` struct that can be unmarshalled from YAML in the consistent way. * There is only single reused helper for creating Transport from this...

I am generally supportive of this, we need this in client_golang, but we can't really expose it to 3rd party callers due to scope and stability guarantees. Common is 0.x,...

Ok, let's try this to put it Go std lib: https://github.com/golang/go/issues/19307#issuecomment-2604710654 (: