EQL: event queries that start with digits fail

[costin]

42 where true throws

org.elasticsearch.xpack.eql.parser.ParsingException: line 1:1: no viable alternative at input '42'

[elasticmachine]

Pinging @elastic/es-search (:Search/EQL)

[rw-access]

This looks correct to me, since 42 isn't a valid identifier. I think this requires escaping, unless you think we should add more explicit handling for it. What's your ideal expected behavior?

`42` where true

[costin]

Usability wise:
The event field is customizable meaning it can keyword or numeric. Even if we restrict it to being a keyword:
event where condition is queryDSL is essentially:
event_field == "event" and ...
event is a value, we just happen to escape it automatically.
So whether it's only letter or numbers should not matter since both are valid values.

`42` where true
is problematic since it means 42 is a field not a value. Which is not the case.

Implementation wise:
I think reusing identifiers is problematic and having a dedicated token for eventType (essentially an unescaped string) would work better.

[rw-access]

Agreed. Since the eventType type depends on the index, I think this needs its own parser rule, accepting identifiers, strings and numbers. I think it's reasonable to support only those and not other types. boolean, etc doesn't make much sense to me.

On a related note (I can make this a separate issue, if it's scope creep), I think it also makes sense to make (eventType "where") optional. The EQL grammar was like this https://github.com/endgameinc/eql/blob/master/eql/etc/eql.g#L13 but that functionality wasn't exposed to the end user. One advantage of this is that we gain more flexibility with data formats.

[costin]

I think it's reasonable to support only those and not other types. boolean, etc doesn't make much sense to me.

By virtue of being non-escaped, even a boolean can be passed in - a rare case but a valid one since true and false are a valid string just like 42: true where ...

On a related note (I can make this a separate issue, if it's scope creep), I think it also makes sense to make (eventType "where") optional. The EQL grammar was like this https://github.com/endgameinc/eql/blob/master/eql/etc/eql.g#L13 but that functionality wasn't exposed to the end user. One advantage of this is that we gain more flexibility with data formats.

Please do create another issue. I'm +1 on it since where true for such cases is simply noise.
Not sure what you mean by data format - can you give an example?

[costin]

Btw since there's agreement on the issue, I'll remove the discuss label.

[rw-access]

Update from 2020/02/13 meeting. We can always move the check to the right of where and use the any type. I think we can indirectly close this, once we add parser rules for any.

Update/clarification: Instead of accepting 42 where true, we'll accept any where event.category == "42"