-
Notifications
You must be signed in to change notification settings - Fork 24.8k
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
CCS controlling node returns a 500 when the data nodes return a 404 #27461
Labels
Comments
@chrisronline can you please post the complete error that you are getting back? |
@javanna Sure, should have included that in the issue.
|
I removed the discuss lable @javanna can you follow up on this?! |
javanna
added
:Search/Search
Search-related issues that do not fall into other categories
>bug
labels
Nov 24, 2017
This still occurs on master
Local search on the "remote" cluster
Search for the same index on the remote cluster
@elastic/es-search-aggs |
javanna
added a commit
to javanna/elasticsearch
that referenced
this issue
May 30, 2018
In case an error is returned when calling search_shards on a remote cluster, which will lead to throwing an exception in the coordinating node, we should make sure that the status code returned by the coordinating node is the same as the one returned by the remote cluster. Up until now a 500 - Internal Server Error was always returned. This commit changes this behaviour so that for instance if an index is not found, which causes an 404, a 404 is also returned by the coordinating node to the client. Closes elastic#27461
javanna
added a commit
that referenced
this issue
Jun 1, 2018
In case an error is returned when calling search_shards on a remote cluster, which will lead to throwing an exception in the coordinating node, we should make sure that the status code returned by the coordinating node is the same as the one returned by the remote cluster. Up until now a 500 - Internal Server Error was always returned. This commit changes this behaviour so that for instance if an index is not found, which causes an 404, a 404 is also returned by the coordinating node to the client. Closes #27461
javanna
added a commit
that referenced
this issue
Jun 1, 2018
In case an error is returned when calling search_shards on a remote cluster, which will lead to throwing an exception in the coordinating node, we should make sure that the status code returned by the coordinating node is the same as the one returned by the remote cluster. Up until now a 500 - Internal Server Error was always returned. This commit changes this behaviour so that for instance if an index is not found, which causes an 404, a 404 is also returned by the coordinating node to the client. Closes #27461
javanna
added a commit
that referenced
this issue
Jun 14, 2018
In case an error is returned when calling search_shards on a remote cluster, which will lead to throwing an exception in the coordinating node, we should make sure that the status code returned by the coordinating node is the same as the one returned by the remote cluster. Up until now a 500 - Internal Server Error was always returned. This commit changes this behaviour so that for instance if an index is not found, which causes an 404, a 404 is also returned by the coordinating node to the client. Closes #27461
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
I have a CCS environment setup, using the guide here. It contains two data nodes and one controlling node. Both data nodes contain the same index,
test
, with a single document in each. One data node is running off:9201
, the other off:9202
. The controlling node is running off:9220
.This request is good:
However, this request is unexpected:
(
curl -XPOST localhost:9220/cluster_one:t/_search -i
andcurl -XPOST localhost:9220/cluster_two:t/_search -i
return the same 500 too.)I'm assuming the connecting node is detecting the 404 from the data nodes and is converting that into a 500, but I'm not sure it should do that. The connecting node should probably inspect the type of error and return the same error type instead of the 500.
The text was updated successfully, but these errors were encountered: