ThanosRuler remote-write version filtering does not remove unsupported fields

Author: priyanshu7739410Created Sep 11, 2026Updated Sep 14, 2026
Labelskind/bug

Is there an existing issue for this?

  • I have searched the existing issues

What happened?

Description

In pkg/thanos/operator.go, createOrUpdateRulerConfigSecret attempts to filter out remote-write fields that are unsupported by older Thanos versions (for example, roundRobinDNS, sendNativeHistograms, or messageVersion).

While the operator logs warnings indicating that these fields are unsupported and will be ignored, the fields remain present in the generated remote-write.yaml configuration secret. This can result in invalid/unsupported configuration being passed to Thanos Ruler.

Steps to Reproduce

  1. Configure a ThanosRuler resource targeting an older Thanos version (e.g. v0.24.0).
  2. Add remote-write configurations with fields unsupported by that version, such as:
    • messageVersion: Version2.0
    • sendNativeHistograms: true
    • roundRobinDNS: true
  3. Inspect the operator logs and the generated configuration secret (<ruler-name>-remote-write).

Expected Result

When the configured Thanos version does not support specific RemoteWrite fields, the operator should remove those fields before generating the Thanos Ruler configuration secret.

Actual Result

The operator logs that the unsupported fields are being ignored, but the generated secret still contains:

yaml
protobuf_message: io.prometheus.write.v2.Request
send_native_histograms: true
round_robin_dns: true

Prometheus Operator Version

bash
main branch (commit a0fcd6e81 / v0.84+)

Kubernetes Version

yaml
N/A  this is a reconciliation logic bug reproducible via unit tests; not tied to a specific cluster version.

Kubernetes Cluster Type

kind

How did you deploy Prometheus-Operator?

prometheus-operator/kube-prometheus

Manifests

yaml
apiVersion: monitoring.coreos.com/v1
kind: ThanosRuler
metadata:
  name: example
  namespace: default
spec:
  image: quay.io/thanos/thanos:v0.24.0
  remoteWrite:
    - url: http://remote-write.example.com
      messageVersion: Version2.0
      sendNativeHistograms: true
      roundRobinDNS: true

prometheus-operator log output

bash
level=warn msg="roundRobinDNS is not supported by thanos, it will be ignored" thanos_version=0.24.0
level=warn msg="sendNativeHistograms is not supported by thanos, it will be ignored" thanos_version=0.24.0

Anything else?

Root cause

In pkg/thanos/operator.go, createOrUpdateRulerConfigSecret iterates over remote-write configurations using:

go
for i, rw := range tr.Spec.RemoteWrite {

Because rw is a value copy of each RemoteWriteSpec, mutations via resetFieldFn(&rw.SendNativeHistograms, ...) or direct assignments (rw.MessageVersion = nil) only modify the local copy rw rather than the element in tr.Spec.RemoteWrite[i].

The configuration is subsequently generated from the unmodified tr.Spec.RemoteWrite slice with version checking disabled:

go
c, err := cg.GenerateRemoteWriteConfig(
    tr.Spec.RemoteWrite,
    prompkg.WithoutVersionCheck(),
)

As a result, unsupported fields persist in the generated configuration despite the warning logs.

Could maintainers please confirm whether this behavior is considered a bug and whether a fix would be welcome? I have a local fix ready (fix(thanos): correctly filter unsupported remote write fields) and can open a PR if this is confirmed.

Source: prometheus-operator/prometheus-operator