Revise get aliases response

[javanna]

The get aliases API response is somewhat unique. As some other API, it mixes errors with valid aliases returned, which makes it quite hard to reason about. I would like us to review whether we want to make any change.

The usual response is something like the following:

curl localhost:9200/index*/_alias?pretty
{
  "index1" : {
    "aliases" : {
      "alias1" : { }
    }
  },
  "index2" : {
    "aliases" : { }
  },
  "index3" : {
    "aliases" : {
      "alias3" : { }
    }
  }
}

In case a requested index doesn't exist, an error gets returned (status 404):

curl localhost:9200/does_not_exist/_alias?pretty
{
  "error" : {
    "root_cause" : [
      {
        "type" : "index_not_found_exception",
        "reason" : "no such index",
        "resource.type" : "index_or_alias",
        "resource.id" : "does_not_exist",
        "index_uuid" : "_na_",
        "index" : "does_not_exist"
      }
    ],
    "type" : "index_not_found_exception",
    "reason" : "no such index",
    "resource.type" : "index_or_alias",
    "resource.id" : "does_not_exist",
    "index_uuid" : "_na_",
    "index" : "does_not_exist"
  },
  "status" : 404
}

When some requested aliases are not found though, the response becomes the following if no aliases are found:

curl 'localhost:9200/_alias/b*?pretty'
{
  "error" : "alias [b*] missing",
  "status" : 404
}

and becomes the following when some aliases are not found and some others are found:

curl 'localhost:9200/_alias/a*,b*?pretty'
{
  "error" : "alias [b*] missing",
  "status" : 404,
  "index1" : {
    "aliases" : {
      "alias1" : { }
    }
  },
  "index2" : {
    "aliases" : {
      "alias2" : { }
    }
  }
}

The error in the response above should probably be wrapped in another object, and the status returned is 404 although some aliases have been returned. Not sure whether that is intended. This was found as part of #28799 as this kind of responses is quite tricky to parse back when adding support for them to the high-level REST client. It is not clear whether we should throw an exception whenever 404 is returned, although in the last case some aliases were found and they would be lost if the client threw an exception. The other problem is that the structure of the "alias not found" error is not compliant to the usual errors that can be parsed back as an ElasticsearchException, which forces us to parse it back as a String. In fact on the server side it is not an exception, it is just how the response is rendered back at REST.

This seems like an example of API that can return "partial results", then the response should probably hold a failure object together with the aliases found?

[elasticmachine]

Pinging @elastic/es-distributed

[jasontedor]

I agree, this does require some rethinking. This arose from #25043 which was a solution for #24644. To summarize:

• our HEAD and GET responses were not aligned; HEAD should always match the output of GET only without the body (e.g., the status code and Content-Length header should be the same)
• historically, HEAD alias was used to check for the existence of an alias and would 404 if an alias was missing
• when we aligned HEAD and GET alias, this broke the use of HEAD alias as an existence check as GET alias did not behave in this way
• to return the use of HEAD alias, we made GET alias behave similarly

This is how we got to where we are today. That said, this is not at all consistent with our other APIs and I agree we should move it to something like you describe with an error object and a realignment of the status code.

[javanna]

thanks @jasontedor for the history. One more thing I recently stumbled upon is that we may or may not return indices without matching aliases, depending on whether an alias was provided in the request or not (#27763). I realize there is even more history around this, but I find that a bit confusing, maybe it is a good time to discuss that too if we revise the get aliases response.