-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support UTF-8 label matchers: Log an error if the parsers produce different parsings #3570
Support UTF-8 label matchers: Log an error if the parsers produce different parsings #3570
Conversation
@gotjosh undecided about what to do here. Do we support escape sequences outside of double quotes (a further relaxation of the grammar?) or do we want to warn users to add double quotes around their matchers that have escape sequences? |
1dd37f2
to
c9fa6a1
Compare
I assume that this means that there is a bug with the current parser as one of the design goals of If it is a breaking change, at what point do we update https://github.com/prometheus/alertmanager/blob/main/matchers/compat/parse_test.go with the scenario we're trying to cover? |
It's not that there is a bug as such, I had omitted openmetrics escape sequences outside double quotes on purpose. The issue is that when we relaxed the grammar to allow unquoted characters other than [a-zA-Z0-9]+, we also permitted escape sequences such as In the UTF-8 matchers parser, these are not un-escaped and kept as-is:
But in the classic parser, these are unescaped as it supports openmetrics:
That said, I'm not convinced we should support openmetrics escape sequences outside double quotes. One option is we make
The fallback mechanism we have ensures that old matchers that do not conform to the grammar still parse. It doesn't ensure there are no breaking changes if the input is valid in both parsers, but produces different parsings. That's what this change does though. I think we can choose between adding openmetrics support and making |
c9fa6a1
to
73d0913
Compare
This commit updates the fallback parser to compare the parsings of both the UTF-8 matchers parser and the classic parser, and log an error if the parsers produce different parsings. This can happen at present if ecsape sequences such as \n and \t are used outside of double quotes, as this is not supported in the UTF-8 matchers parser. Signed-off-by: George Robinson <george.robinson@grafana.com>
73d0913
to
9955d49
Compare
Signed-off-by: George Robinson <george.robinson@grafana.com>
I'm going to close this as I'm not 100% sure it's needed. |
This commit updates the fallback parser to compare the parsings of both the UTF-8 matchers parser and the classic parser, and log an error if the parsers produce different parsings.
This can happen at present if escape sequences such as
\n
and\\
are used outside of double quotes, as these are not un-escaped in the UTF-8 matchers parser, leaving them as literal\n
and\\
.The risk here is that without this change, a small number of Alertmanager user's routes might break on upgrade and without warning.