Skip to content

[API] Index path parameters shouldn't be treated as wildcards in handlers #79808

Open

Description

Today when using a new API against an old cluster or using an API without the correct plugin installed can result in errors complaining about "invalid index name" even though an index parameter isn't being used. For example using the fleet.search API on 8.0-SNAPSHOT yields:

{
  "error": {
    "root_cause": [
      {
        "type": "invalid_index_name_exception",
        "reason": "Invalid index name [_fleet], must not start with '_'.",
        "index_uuid": "_na_",
        "index": "_fleet"
      }
    ],
    "type": "invalid_index_name_exception",
    "reason": "Invalid index name [_fleet], must not start with '_'.",
    "index_uuid": "_na_",
    "index": "_fleet"
  },
  "status": 400
}

This can be confusing to users as the error message points to a problem with an index name instead of an absence of the API handler.

This issue also impacts our developers: API namespaces aren't as useful for plugin APIs as they still need to consider other API names to provide positive UX in their absence.

Proposed solution

Instead of using a wildcard for <index> path parts, instead don't match path parts with a leading underscore (except _all). This will lead to errors that more closely match the situation of an API not being available instead of anything to do with index names:

{
  "error": "no handler found for uri [/_fleet/_search] and method [POST]"
}

References:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions