Fix indices.delete_alias response

[pquentin]

This regressed between March 25th and April 15th, back when recording examples wasn't stable. Unfortunately, 22 days worth of commits is a lot: elastic/elasticsearch@e9fcb0a...d3e0ec1. If we find where this is set, we could consider asking the Elasticsearch team to not do this. It's not helpful, as acknowledged is already set to true.

Another option: I could only change the delete_alias body instead of affecting all APIs that use AcknowledgedResponseBase.

[l-trotta]

I can't find this in the sever, AcknowledgeResponse only has one field. I think the problem is the fact that the body changes when there's an error, so for a normal response it's:

{
  "acknowledged": true
}

while when there's an error it's:

{
  "error": {
    "root_cause": [
      {
        "type": "illegal_argument_exception",
        "reason": "unable to put stored script with unsupported lang [painlesss]"
      }
    ],
    "type": "illegal_argument_exception",
    "reason": "unable to put stored script with unsupported lang [painlesss]"
  },
  "status": 400
}

in the spec we just map the first one, because the second case is the exception case (the server returns 404) so what java does is that it returns the error body in the exception message.

[pquentin]

Actually, we also get responses like this one:

{
  "api": "indices.delete_alias",
  "file": "/test/free/indices.delete_alias/all_path_options.yml",
  "name": "check delete with prefix* index",
  "origin": "yaml",
  "request": {
    "args": {
      "index": "test_*",
      "name": "alias1"
    }
  },
  "response": {
    "headers": {
      "content-encoding": "gzip",
      "content-length": "62",
      "content-type": "application/json",
      "x-elastic-product": "Elasticsearch"
    },
    "payload": {
      "acknowledged": true,
      "errors": false
    },
    "statusCode": 200
  }
}

[l-trotta]

ooh that's why: it's a subclass! we have to map this

[l-trotta]

update: it's more complex than it looks, I'm still working on this. in particular it seems like in case of error it can return detailed information, including a class that represents an ElasticsearchException which I don't think we already have. outdated

[l-trotta]

@pquentin sorry I forgot about this, rebased it + added a commit with what I think is the solution

[github-actions]

Following you can find the validation changes against the target branch for the API.

API	Status	Request	Response
indices.delete_alias	🔴 → 🟢	12/12	5/12 → 12/12

You can validate this API yourself by using the make validate target.

[pquentin]

@l-trotta Sorry for not getting back to you sooner here. Should we add action_results too? elastic/elasticsearch#106514

[pquentin]

Never mind, action_results only applies to `indices.update_aliases.

[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-2951-to-8.19
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 49262849630d994f02e5f903638ef795de9152f1
# Push it to GitHub
git push --set-upstream origin backport-2951-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-2951-to-8.19.

[pquentin]

💚 All backports created successfully

Status	Branch	Result
✅	8.19

Questions ?

Please refer to the Backport tool documentation