Loki db doesn't allow most of the keywords to be name of labels. So when you use label names such as json, logfmt ,... Loki returns error. However for ip, Loki doesn't return the error and it is accepted label name. Therefore our lezer parser should behave the same.
This PR updates a logic for IP filter and makes it extends Identifier
There is another operator similar to @specialize, called @extend. Whereas specialized tokens replace the original token, extended tokens allow both meanings to take effect, implicitly enabling GLR when both apply. This can be useful for contextual keywords where it isn't clear whether they should be treated as an identifier or a keyword until a few tokens later.
We already use this for other logql keywords.
I have added additional test to ensure that ip label name is treated the same way as any other label name and it doesn't affect using ip filter in the query.
Also this PR bumps package to 0.2.3 and update changelog.
Loki db doesn't allow most of the keywords to be name of labels. So when you use label names such as
json,logfmt,... Loki returns error. However forip, Loki doesn't return the error and it is accepted label name. Therefore our lezer parser should behave the same.This PR updates a logic for IP filter and makes it extends
IdentifierMore on this from documentation https://lezer.codemirror.net/docs/guide/#token-specialization
We already use this for other logql keywords.
I have added additional test to ensure that
iplabel name is treated the same way as any other label name and it doesn't affect usingipfilter in the query.Also this PR bumps package to 0.2.3 and update changelog.