Description
The get and list APIs for ESQL should use the same async execution id format that the async API uses. You should be able to do a _query/async which returns an id and use that id immediately in the get running query API.
The API also shouldn't return node, coordinating_node, or data_node or anything. That's a concept that's not universally applicable. So:
{ "queries" : {
"abc:1234": { <---- use the encoding returned by async search
"node": "abc", <---- zap this
"id": 1234, <---- zap this
"start_time_millis": 14585858875292,
"running_time_nanos": 762794,
"query": "FROM logs* | STATS BY hostname"
},
"abd:1729": { <---- use the encoding returned by async search
"node": "abd", <---- zap this
"id":1729, <---- zap this
"start_time_millis": 14585858823573,
"running_time_nanos": 90231,
"query": "FROM orders | LOOKUP country_code ON country"
}
}
}
GET /_query/queries/abc:1234 <---- use the encoding returned by async search
{
"id": 1234, <---- zap this
"node": "abc", <---- zap this
"start_time_millis": 14585858875292,
"running_time_nanos": 762794,
"query": "FROM logs* | STATS BY hostname"
"coordinating_node": "oTUltX4IQMOUUVeiohTt8A" <---- zap this
"data_nodes" : [ "DwrYwfytxthse49X4", "i5msnbUyWlpe86e7"] <---- zap this
}
Description
The get and list APIs for ESQL should use the same async execution id format that the async API uses. You should be able to do a
_query/asyncwhich returns anidand use thatidimmediately in the get running query API.The API also shouldn't return
node,coordinating_node, ordata_nodeor anything. That's a concept that's not universally applicable. So: