Skip to content
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

We should enforce these required inputs by returning a useful error and 400 response. right now it is 500 #780

Closed

Conversation

autata
Copy link
Contributor

@autata autata commented Feb 22, 2024

Summary

I think we should set a reasonable default for when size is missing (10? - i think that is what ES uses when missing). Opening a draft PR as a discussion before going further in this direction. There may be a better way to more closely follow the ES API spec. (_msearch, range query docs)

For lte and gte I think if they are missing, we should return a 400 (Bad Request) and a helpful error string.

Right now, if any of these are missing, we get a 500 (Internal Server Error) response.

Requirements

private static int getHowMany(JsonNode body) {
return body.get("size").asInt();
}

// This is required. consider returning a more useful error to the user than 500
Copy link
Contributor Author

@autata autata Feb 22, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably something like this:

{
"error": {
"code": 400,
"message": "Bad Request",
"details": "The 'query.gte' field is required but missing in the request."
}
}

@bryanlb
Copy link
Contributor

bryanlb commented Feb 27, 2024

@autata we are looking to next quarter or the following to move to using the Opensearch library for the entire request parsing, which should allow us better compatibility with these fields and options. Currently we do this for a subsection of the request (aggregations), and would like to extend this to the entire request body. This should allow us to support more complex request types that are not currently issued via Grafana today.

@autata
Copy link
Contributor Author

autata commented Feb 28, 2024

@bryanlb this is helpful context. Do you think it makes sense to open a PR with slightly better return codes (as suggested in these comments) or potentially change this to an issue since following Opensearch API is in the roadmap for the next quarter or two and this would be fixed if moving to Opensearch full functionality.

@bryanlb
Copy link
Contributor

bryanlb commented Feb 29, 2024

@autata I think that moving this to an issue makes the most sense here. If you still want to PR a change to these response codes that would be fine, but if all goes according to plan this would only be in place for a few months before we can entirely rework the request parsing.

@autata autata mentioned this pull request Mar 12, 2024
3 tasks
@autata
Copy link
Contributor Author

autata commented Mar 12, 2024

@bryanlb opened an issue for tracking: #798

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

Successfully merging this pull request may close these issues.

None yet

2 participants