What did you do?

We use the PromQL parser in the Parca project. We noticed something interesting when label values contained the \x2d value. Ultimately we noticed that the PromQL parser interprets this, not as the string value, but rather interprets the UTF-8 escape character, which in this case is the dash (-).

A resulting inconsistency can be triggered using the following config:

scrape_configs:
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]
        labels:
          faulty_label: \x2d

Then query Prometheus, for example using the prometheus_build_info metric.

If we then use the UI to copy the label-matcher, and insert it into the query and query, however, we get an empty result.

Only if we explicitly escape the label value do we get the result we were looking for with the previous query:

What did you expect to see?

I expected one of the following two, for Prometheus' behavior to be consistent within itself:

• The PromQL parser retains the actual string literal and does not interpret the UTF-8 escape character.
• Table renders the label-value in its escaped form, the autocompletion suggests the label-value in its escaped form, and therefore copying the matcher by clicking on it in the table also uses the escaped form.

What did you see instead? Under which circumstances?

Described in the first section.

System information

Darwin 21.6.0 arm64

Prometheus version

$ ./prometheus --version
prometheus, version 2.40.3 (branch: HEAD, revision: 84e95d8cbc51b89f1a69b25dd239cae2a44cb6c1)
  build user:       root@692b092db288
  build date:       20221124-09:15:54
  go version:       go1.19.3
  platform:         darwin/arm64

Prometheus configuration file

scrape_configs:
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]
        labels:
          faulty_label: \x2d