Allow comment in request payload to be returned in the response payload.

[linker-c]

The idea is very similar to "X-Opaque-ID" from http request header. But make it part of the payload so the value will be available in all aspect of debugging.
X-Opaque-ID only shows up for slow logs, which is not friendly enough IMO.
I often use kibana to see detailed task and any query taking too long will be spotted easily. Especially performance degradation over time.
The problem for me is that I have no idea who made that request and under what context. The coders don't even know most of the time.

If there's a boolean flag that allows us to return the comment from request payload, then I can easily use comment as an ID.
It will speed up troubleshooting significantly.

[elasticmachine]

Pinging @elastic/es-core-infra (:Core/Infra/Logging)

[costin]

To clarify, are you asking for X-Opaque-ID to be returned or for any comment inside the request to be returned?
In general, the issue with HTTP headers being promoted in the payload is that breaks the line between meta-data and concrete data. For example, all ES APIs support HTTP requests, many support multiple formats, typically JSON but also BSON, Smile, etc.. In a similar fashion, HTTP headers are well defined but the payload itself is not, assuming JSON, should the comment sit at the top or anywhere in the request. If the payload gets wrapped by another API (which uses it internally) what should happen then?
There's also the issue of dealing with potentially malicious comment - making it part of the payload, it is being fed to all its consumers.

Since you mentioned troubleshooting, would getting access to X-Opaque-ID on all requests help?

[cjcenizal]

Seems related to the enhancement request to support comments in the body of requests in Console (elastic/kibana#11973), which has been requested a few times.

[linker-c]

@costin .
I am thinking more like a boolean flag in the body. I believe it's easier for most folks. We don't typically touch http headers in the code. It'll be more work changing headers per context.

A flag like {"track_total_hits": true }, or {"profile" : true } is what I'm thinking.
@cjcenizal , yes it's related. But I am asking for the returned payload.

For example:

POST sites/_search {
  // From AI model 3
   "return_comment": true
}

And the payload looks something like this

{
  "took" : 1,
  "timed_out" : false,
  "_shards" : { ... },
  **"comment": "From AI model 3",**
  "hits" : { ...  },
    "max_score" : 1.0,
    "hits" : [
      { "name": "xyz"},
      { "name": "abc"},
          ...
     ]
}

Maybe just return the first comment or concatenate all into 1 is fine too.
If this specific query is having an issue or long query/indexing time, I can easily see the caller is "From AI model 3", etc.

If you guys are going to do this, please also honor this flag in your own internal display.
So we can get the benefit through out the system.
Like the payload for this one:

GET _cat/tasks?v&detailed=true

Thanks.

[costin]

Supporting arbitrary elements alongside the response is problematic, see some of the examples in my previous comment.
I understand the angle that you are coming from however I have issues with generalizing this concept across ES APIs.
For example I can see the use of getting access to X-Opaque-ID inside each request and potentially in the logs but changing the actual response is too impactful.

For your particular use-case, I recommend creating your own plugin which can enhance the request/response to your preference. This should help move things forward and also validate your ideas.

[linker-c]

Maybe returning result of X-Opaque-ID to all access is easier.
Let's do that instead then if possible.

Thanks.