Fix CrossClusterEsqlRCSEnrichUnavailableRemotesIT failing tests #119977
Conversation
quux00
added
>non-issue
auto-backport
|
Pinging @elastic/es-search-foundations (Team:Search Foundations) |
quux00
force-pushed
the
test-fix/CrossClusterEsqlRCSEnrichUnavailableRemotesIT
branch
from
43ec53f to
4c78cef
Compare
|
I have a question: is there a reason why this test failure occurs only on Windows? I tried to get this issue to reproduce this on a Windows machine but couldn't, even with the same seed. |
…rEsqlRCSEnrichUnavailableRemotesIT
| @@ -185,8 +187,7 @@ private void esqlEnrichWithSkipUnavailableTrue() throws Exception { | |||
| Map<String, ?> failuresMap = (Map<String, ?>) remoteClusterFailures.get(0); | |||
|
|
|||
| Map<String, ?> reason = (Map<String, ?>) failuresMap.get("reason"); | |||
| assertThat(reason.get("type").toString(), equalTo("connect_transport_exception")); | |||
| assertThat(reason.get("reason").toString(), containsString("Unable to connect to [my_remote_cluster]")); | |||
There was a problem hiding this comment.
I wonder if we could keep the check that the error message mentions my_remote_cluster (if that's the case) maybe without requiring all other stuff to match.
There was a problem hiding this comment.
Since I'm not able to reproduce the failure, I'm hesitant to do that. We don't control what error messages come from the underlying transport layer, so testing for that doesn't test for anything we can change. The error message will be whatever the transport layer decides it wants it to be depending on what exact sequence of transport issues happened (and there can be many different errors from disconnected clusters). The key point of this test is that it reports some sort of disconnected/transport error rather than an ESQL verification exception which is what it was doing before Pawan's fix.
…rEsqlRCSEnrichUnavailableRemotesIT
Fixes #119910