Fix EsqlResults type to match the actual output

[smalyshev]

Example output:

{
"_clusters": {
    "total": 2,
    "successful": 1,
    "running": 0,
    "skipped": 1,
    "partial": 0,
    "failed": 0,
    "details": {
      "(local)": {
        "status": "successful",
        "indices": "my-index",
        "took": 25,
        "_shards": {
          "total": 1,
          "successful": 1,
          "skipped": 0,
          "failed": 0
        }
      },
      "remote1": {
        "status": "skipped",
        "indices": "my-index2",
        "took": 17,
        "_shards": {
          "total": 0,
          "successful": 0,
          "skipped": 0,
          "failed": 0
        },
        "failures": [
          {
            "shard": -1,
            "index": null,
            "reason": {
              "type": "verification_exception",
              "reason": "Unknown index [remote1:my-index2]"
            }
          }
        ]
      }
    }
  }
}

[github-actions]

Following you can find the validation results for the APIs you have changed.

API	Status	Request	Response
esql.async_query_delete	⚪	Missing test	Missing test
esql.async_query_get	⚪	Missing test	Missing test
esql.async_query_stop	⚪	Missing test	Missing test
esql.async_query	⚪	Missing test	Missing test
esql.get_query	⚪	Missing test	Missing test
esql.list_queries	⚪	1/1	Missing test
esql.query	⚪	317/317	Missing test

You can validate these APIs yourself by using the make validate target.

[github-actions]

Following you can find the validation results for the APIs you have changed.

API	Status	Request	Response
esql.async_query_delete	⚪	Missing test	Missing test
esql.async_query_get	⚪	Missing test	Missing test
esql.async_query_stop	⚪	Missing test	Missing test
esql.async_query	⚪	Missing test	Missing test
esql.get_query	⚪	Missing test	Missing test
esql.list_queries	⚪	1/1	Missing test
esql.query	⚪	317/317	Missing test

You can validate these APIs yourself by using the make validate target.

[l-trotta]

@smalyshev is this the correct output from 8.19/9.1? so the current one is correct for 8.18/9.0? is there a reference server PR with the changes?

[smalyshev]

@l-trotta the one in the description is the correct one for 8.18/9.0 too, I need to check what happens for the specs in these versions, thanks for pointing it out. Probably need to add more backports.

[github-actions]

The backport to 8.19 failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-8.19 8.19
# Navigate to the new working tree
cd .worktrees/backport-8.19
# Create a new branch
git switch --create backport-4515-to-8.19
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 5572fbecf6401eeb634e7ebc730036f64eb8edc1
# Push it to GitHub
git push --set-upstream origin backport-4515-to-8.19
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-8.19

Then, create a pull request where the base branch is 8.19 and the compare/head branch is backport-4515-to-8.19.

[github-actions]

The backport to 8.18 failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-8.18 8.18
# Navigate to the new working tree
cd .worktrees/backport-8.18
# Create a new branch
git switch --create backport-4515-to-8.18
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 5572fbecf6401eeb634e7ebc730036f64eb8edc1
# Push it to GitHub
git push --set-upstream origin backport-4515-to-8.18
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-8.18

Then, create a pull request where the base branch is 8.18 and the compare/head branch is backport-4515-to-8.18.

[smalyshev]

Looks like 8.18 and 8.19 don't have this type documented, so not backporting.