New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include suppressed exceptions in rest response? #23392

Closed
martijnvg opened this Issue Feb 27, 2017 · 1 comment

Comments

Projects
None yet
1 participant
@martijnvg
Member

martijnvg commented Feb 27, 2017

On the transport layer suppressed exceptions are being kept around (in ElasticsearchException#readStackTrace(...) and Elasticsearch#writeStackTraces(...)), so maybe we should include suppressed exceptions in rest response too? Or at least give the ability to do this via a rest parameter.

In the put pipeline api this can be useful as all the config errors can then be returned instead of failing on the first configuration error. Obviously other apis can benefit from this as well.

@martijnvg

This comment has been minimized.

Member

martijnvg commented Apr 14, 2017

Discussed this at fix-it-friday and it makes sense to include suppressed exceptions in the rest response. Further more it makes sense to include suppressed exceptions by default, it shouldn't blow up the response, because the stacktraces aren't rendered by default.

@martijnvg martijnvg added help wanted and removed discuss labels Apr 14, 2017

nik9000 added a commit to nik9000/elasticsearch that referenced this issue Mar 16, 2018

REST: Include suppressed exceptions on failures
This modifies xcontent serialization of Exceptions to contain suppressed
exceptions. If there are any suppressed exceptions they are included in
the exception response by default. The reasoning here is that they are
fairly rare but when they exist they almost always add extra useful
information. Take, for example, the response when you specify two broken
ingest pipelines:

```
{
  "error" : {
    "root_cause" : ...snip...
    "type" : "parse_exception",
    "reason" : "[field] required property is missing",
    "header" : {
      "processor_type" : "set",
      "property_name" : "field"
    },
    "suppressed" : [
      {
        "type" : "parse_exception",
        "reason" : "[field] required property is missing",
        "header" : {
          "processor_type" : "convert",
          "property_name" : "field"
        }
      }
    ]
  },
  "status" : 400
}
```

Moreover, when suppressed exceptions come from 500 level errors should
give us more useful debugging information.

Closes elastic#23392

nik9000 added a commit that referenced this issue Mar 19, 2018

REST: Include suppressed exceptions on failures (#29115)
This modifies xcontent serialization of Exceptions to contain suppressed
exceptions. If there are any suppressed exceptions they are included in
the exception response by default. The reasoning here is that they are
fairly rare but when they exist they almost always add extra useful
information. Take, for example, the response when you specify two broken
ingest pipelines:

```
{
  "error" : {
    "root_cause" : ...snip...
    "type" : "parse_exception",
    "reason" : "[field] required property is missing",
    "header" : {
      "processor_type" : "set",
      "property_name" : "field"
    },
    "suppressed" : [
      {
        "type" : "parse_exception",
        "reason" : "[field] required property is missing",
        "header" : {
          "processor_type" : "convert",
          "property_name" : "field"
        }
      }
    ]
  },
  "status" : 400
}
```

Moreover, when suppressed exceptions come from 500 level errors should
give us more useful debugging information.

Closes #23392

nik9000 added a commit that referenced this issue Mar 19, 2018

REST: Include suppressed exceptions on failures (#29115)
This modifies xcontent serialization of Exceptions to contain suppressed
exceptions. If there are any suppressed exceptions they are included in
the exception response by default. The reasoning here is that they are
fairly rare but when they exist they almost always add extra useful
information. Take, for example, the response when you specify two broken
ingest pipelines:

```
{
  "error" : {
    "root_cause" : ...snip...
    "type" : "parse_exception",
    "reason" : "[field] required property is missing",
    "header" : {
      "processor_type" : "set",
      "property_name" : "field"
    },
    "suppressed" : [
      {
        "type" : "parse_exception",
        "reason" : "[field] required property is missing",
        "header" : {
          "processor_type" : "convert",
          "property_name" : "field"
        }
      }
    ]
  },
  "status" : 400
}
```

Moreover, when suppressed exceptions come from 500 level errors should
give us more useful debugging information.

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