Andriy Redko

> Makes sense @reta, so what is a proposed change to be able to extract a 409 Conflict? Thanks @dblock , this is already working this way, the `OpenSearchException` is...

> @rursprung That could make sense, but maybe it's easier if `ResponseException` exposes a status field? Thanks @rursprung , or `OpenSearchClient#create` should indeed throw `OpenSearchException` in this case?

> We should probably do both. I don't see a reason why `ResponseException` wouldn't have `status`. Agree, at least it is worth looking, the reasons why `ResponseException` may not have...

> i've created #756 to expose `ResponseException#status` Thanks @rursprung , I think this is good change in any case, thank you. > as you're far more familiar with this library...

Thanks @AmiStrn , that's the real issue, we are looking into multiple ways to deal with that: - https://github.com/opensearch-project/opensearch-java/pull/366 - https://github.com/opensearch-project/opensearch-java/pull/336 - https://github.com/opensearch-project/opensearch-java/issues/284 - https://github.com/opensearch-project/opensearch-clients/issues/55 As of now, we are...

PS: This is not just `opensearch-java` issue but covers all clients fleet.

Thanks a lot @peterzhuamazon !

> By partitioning the tests, we can mitigate the impact of flakiness and ensure more reliable test runs. I think as a workaround, grouping looks like a step in right...

Thanks @zelinh , it makes perfect sense > What do you think about any of specific smoke tests (any API requests) from Core perspective that we could start on? @reta...

> In our validation workflow the most we did was to call 9200/5601 port, list plugin, check cluster status and that is it. I assume we need to call more...