Timestamp parsing in ElasticSearch API Issues

[gjacoby126]

I recently tried to query the KalDB version of ElasticSearch's msearch library and got an HTTP 500 back. Upon looking at the server logs, I found a NullPointerException coming from OpenSearchRequest.getStartTimeEpochMs.

return body.get("query").findValue("gte").asLong();

The root cause was that my query didn't have a required timestamp range. This is a reasonable restriction, but the existing logic has some issues:

1. The query parsing shouldn't create an NPE, which leads to an HTTP 500 response, which is incorrect. (It should be a 400 Bad Request, or similar, because the actual problem was my query. )
2. It would be preferable for KalDB to return a helpful error message to the client explaining that the timestamp range filter is required.
3. The existing logic assumes that any use of "gte" is start timestamp filter. What if a user is filtering start timestamp by "gt" or "eq" instead?
4. The existing logic assumes that any use of "lte" is the end timestamp filter. What if a user is filtering end timestamp by "lt" or "eq"?
5. What if a user is submitting a more complex ElasticSearch query with range filters on multiple fields? There's currently no logic ensuring that the "gte" or "lte" found corresponds to the timestamp field that KalDB is using as a partition key. The "findValue" Jackson method will return the first instance found.

[github-actions]

This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[bryanlb]

This is related to #798