OpenSearch icon indicating copy to clipboard operation
OpenSearch copied to clipboard

[BUG] generic "No OpenSearchException found" error if http.detailed_errors is disabled

Open rursprung opened this issue 3 years ago • 0 comments

Describe the bug if http.detailed_errors.enabled: false is set then the error message in a REST API call will only report back an error message if the exception contains an OpenSearchException: https://github.com/opensearch-project/OpenSearch/blob/465771631d2e3a5001d97d0c7e845e6f8ea6bd15/server/src/main/java/org/opensearch/OpenSearchException.java#L595-L608

(note: confusingly enough this method is a static member of OpenSearchException but handles any Exception, IMHO it might be better located e.g. in ExceptionsHelper?)

there are however (many?) cases where this isn't the case, e.g. when trying to update a setting through the settings API which doesn't support it (fun-fact: i noticed it when trying to update the http.detailed_errors.enabled setting). this returns an IllegalArgumentException instead.

To Reproduce

  1. start a cluster with http.detailed_errors.enabled: false
  2. call PUT /_cluster/settings with a setting which doesn't support it, e.g.:
    {
        "persistent": {
            "http.detailed_errors.enabled": true
        }
    }
    

with http.detailed_errors.enabled: false (as in the reproduction case) it gives the following - useless - response:

{
    "error": "No OpenSearchException found",
    "status": 400
}

with the default settings (or explicitly http.detailed_errors.enabled: true) it gives the following response:

{
    "error": {
        "root_cause": [
            {
                "type": "illegal_argument_exception",
                "reason": "persistent setting [http.detailed_errors.enabled], not dynamically updateable"
            }
        ],
        "type": "illegal_argument_exception",
        "reason": "persistent setting [http.detailed_errors.enabled], not dynamically updateable"
    },
    "status": 400
}

Expected behavior the error message gives a hint at the cause as here the cause is clearly on the side of the caller. without the message the caller has no way of knowing what to do to fix the issue.

otherwise the message should at least be in the server log, but this isn't the case either (with default log settings). that way no information leakage would happen but it'd still be possible to understand the cause of a failure (for people with access to the system which should be the only ones which can do config updates via APIs).

Plugins (irrelevant, this is about core functionality)

Screenshots n/a

Host/Environment (please complete the following information): OpenSearch 2.2.0 running in a linux container

Additional context see the following related tickets:

  • https://github.com/opensearch-project/OpenSearch/issues/4255
  • https://github.com/opensearch-project/documentation-website/issues/1235

rursprung avatar Sep 19 '22 12:09 rursprung