-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[inspector] show request method, path, and querystring #167544
Conversation
…g" (elastic#167485)" This reverts commit 239e503.
…-ref HEAD~1..HEAD --fix'
💛 Build succeeded, but was flaky
Failed CI StepsTest Failures
Metrics [docs]Module Count
Public APIs missing comments
Async chunks
Public APIs missing exports
Page load bundle
Unknown metric groupsAPI count
To update your PR or re-run it, just comment with: |
Pinging @elastic/kibana-presentation (Team:Presentation) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes in 933a5ac LGTM! Nice updates to the integration tests especially to ensure the response is sanitized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
Is it expected that Inspector in Graph and Vega apps does not show request params yet?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By changing reportServerError
we're changing the behaviour of a lot of server APIs owned by other teams. We should rather limit this behaviour change to the data plugin only.
/** | ||
* HTTP request parameters from elasticsearch transport client t | ||
*/ | ||
requestParams?: ConnectionRequestParams; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we construct a dedicated type that only includes the information we intend to send back?
@@ -43,6 +56,7 @@ export function reportServerError(res: KibanaResponseFactory, err: KbnServerErro | |||
body: { | |||
message: err.message, | |||
attributes: err.errBody?.error, | |||
...(err.requestParams ? { requestParams: err.requestParams } : {}), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
KbnServerError
and reportServerError
are widely used outside of data plugin for catching any kind of error in route handlers. It's risky to return the 'requestParams' for all the places this gets used and this would also not be a pattern that we'd recommend gets widely adopted.
We should rather move this functionality and sanitizeRequestParams
into the data plugin.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure I understand, are you suggesting not using KbnServerError and reportServerError in data plugin?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, we could create a new reportElasticsearchErrorAndRequestParams
(naming tbd) in the data plugin and leave the reportServerError
util as-is so we don't change the APIs of any other plugins/teams.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, I will do that. That aligns well with another effort to return rawResponse from data plugin search endpoints, #167099. I will work #167099 first to migrate data search plugin away from KbnServerError and reportServerError so that rawResponse is included in error response. Then I can circle back to this PR and build off of those data plugin only utility methods
'method' | 'path' | 'querystring' | ||
>; | ||
|
||
export function sanitizeRequestParams(requestParams: ConnectionRequestParams) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
export function sanitizeRequestParams(requestParams: ConnectionRequestParams) { | |
export function sanitizeRequestParams(requestParams: ConnectionRequestParams): SanitizedConnectionRequestParams { |
Closes #167099 #### Problem `/bsearch` and `/search` APIs only return `error` key from elasticsearch error response. This is problematic because Inspector needs `rawResponse` to populate "Clusters and shards" While working on this issue, I discovered another problem with how error responses are added to inspector requestResponder. The `Error` instance is added as `json` key. This is a little awkward since the response tab just stringifies the contents of `json`, thus stringifing the Error object instead of just the error body returned from API. This PR address this problem by setting `json` to either `attributes` or `{ message }`. #### Solution PR updates `/bsearch` and `/search` APIs to return `{ attributes: { error: ErrorCause, rawResponse }}` for failed responses. Solution avoided changing KbnServerError and reportServerError since these methods are used extensivly throughout Kibana (see #167544 (comment) for more details). Instead, KbnSearchError and reportSearchError are created to report search error messages. #### Test 1) install web logs sample data set 2) open discover 3) add filter ``` { "error_query": { "indices": [ { "error_type": "exception", "message": "local shard failure message 123", "name": "kibana_sample_data_logs", "shard_ids": [ 0 ] } ] } } ``` 4) Open inspector. Verify "Clusters and shards" tab is visible and populated. Verify "Response" tab shows "error" and "rawResponse" keys. <img width="500" alt="Screenshot 2023-10-09 at 9 29 16 AM" src="https://github.com/elastic/kibana/assets/373691/461b0eb0-0502-4d48-a487-68025ef24d35"> <img width="500" alt="Screenshot 2023-10-09 at 9 29 06 AM" src="https://github.com/elastic/kibana/assets/373691/9aff41eb-f771-48e3-a66d-1447689c2c6a"> --------- Co-authored-by: kibanamachine <[email protected]> Co-authored-by: Gloria Hornero <[email protected]>
Replacing with #169970. |
Closes #45931 PR updates data plugin `search` and `bsearch` endpoints to return method, path, and querystring request params from elasticsearch-js client requests. This provides inspector with the exact details used to fetch data from elasticsearch, ensuring inspector displays request exactly as used by elasticsearch-js client. **ESQL** This PR makes it possible to open ESQL searches in console. <img width="500" alt="Screen Shot 2023-09-16 at 4 19 58 PM" src="https://github.com/elastic/kibana/assets/373691/56019fb5-ca88-46cf-a42f-86f5f51edfcc"> ### background If you are thinking to yourself, "haven't I reviewed this before?", you are right. This functionality has been through several iterations. 1) Original PR #166565 was reverted for exposing `headers`. 2) [Fix to only expose method, path, and querystring keys from request parameters](#167544) was rejected because it applied changes to `kibana_utils/server/report_server_error.ts`, which is used extensively throughout Kibana. 3) This iteration moves logic into the data plugin to be as narrow as possible. --------- Co-authored-by: kibanamachine <[email protected]>
Reinstates changes from #166565. Original changes reverted by #167485. This PR only returns
method
,path
, andquerystring
keys from request parameters.When reviewing, 933a5ac are the changes that resolve the issue and the only different changes from the revert of the revert.
I updated the integration tests to check entire requestParams object instead of individual keys. This gives us a guarentee that 'headers' is not getting returned from the API since it will fail these tests.