-
Notifications
You must be signed in to change notification settings - Fork 107
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
[BUG] The Search API (in Version 3.0.0) is not working without setting an Index #470
Comments
Tanks for reporting this issue. Can you please tell what you client looks like? Are you using AWS Signing or something like that, as I can not reproduce it with our integration tests and I want to adjust them so it does not happen again. |
Thanks for the fast response. I tried it out in a local test setup: return v3api.NewClient(
v3api.Config{
Client: osV3.Config{
Username: config.OS_USER,
Password: config.OS_PASSWORD,
Addresses: []string{config.OS_URL},
Transport: &http.Transport{
TLSClientConfig: &tls.Config{InsecureSkipVerify: true},
},
},
}) |
Hm, weird. I can't seem to reproduce the issue with the integration test. I did the same requests and tried to modify the client address but it does not affect it. If I understand the URL lib correctly it should not matter if the leading slash is missing. I tried looking into this for a few hours but I don't want to dig through the net/http lib to much. It there any chance you can find where this issue is exactly coming from so we can test it as I am not able to reproduce it. |
The error happens on the server side. are you testing against a real endpoint? When the "/" is missing the server responds with statuscode 400. |
I am testing against a real opensearch container. Running I am still not getting where exactly the missing |
You are probably right with the nginx, but I have no access to it to see the logs. Will ask for access and come back to you soon. |
Maybe you can get the requests using the Logger functionality in the client? |
Thanks for the hint with the logger within the client. I tried it out and this is my result. 2024-03-12T09:55:37Z POST https://myurl/_search [status:400 request:183ms]
< <html>
< <head><title>400 Bad Request</title></head>
< <body>
< <center><h1>400 Bad Request</h1></center>
< <hr><center>nginx</center>
< </body>
< </html> Result with my fix (path = "/_search"): 2024-03-12T09:50:32Z POST https://myurl/_search [status:200 request:1.082s]
< {"took":45,"timed_out":false,"_shards":{"total":659,"successful":659,"skipped":658,"failed":0},"hits":{"total":{"value":0,"relation":"eq"},"max_score":null,"hits":[]}} The strange thing is, that the POST call printed out by the logger looks equal! |
Hi again, |
@dom192 want to try to make a fix yourself? start by writing a unit test that shows the problem? |
What is the bug?
It seems, that it is not possible to call the Search function of Client:
without setting
Indices
in theSearchReq
.How can one reproduce the bug?
Call the Search function without specifying Indices
What is the expected behavior?
The expected result should be no error and a valid opensearch result, but instead I get an error:
error msg: failed to json unmarshal body: invalid character '<' looking for beginning of value
The root cause of the problem is getting a http status code 400 Bad Request with http body:
"<html>\r\n<head><title>400 Bad Request</title></head>\r\n<body>\r\n<center><h1>400 Bad Request</h1></center>\r\n<hr><center>nginx</center>\r\n</body>\r\n</html>\r\n"
Which is not handled right. The code tries to
json.Unmarshal
the html and generates the misleading error message.What is your host/environment?
Ubuntu 22.04.3 LTS
API version 3 (github.com/opensearch-project/opensearch-go/v3/opensearchapi)
Do you have any screenshots?
no
Do you have any additional context?
I debugged the issue and found the root cause I think. The problem is the
GetRequest
function:In case of no Indices is set, path is set to _search
this causes the Bad Request response. To fix this I appended a "/" to _search:
after that the everything worked like expected :)
The text was updated successfully, but these errors were encountered: