# Default IndicesOptions in SearchRequest and disable specific deprecation warnings

**URL:** <https://discuss.elastic.co/t/default-indicesoptions-in-searchrequest-and-disable-specific-deprecation-warnings/299242>\
**Category:** Elasticsearch\
**Tags:** language-clients\
**Created:** [March 9, 2022, 4:20pm UTC](https://discuss.elastic.co/t/default-indicesoptions-in-searchrequest-and-disable-specific-deprecation-warnings/299242 "2022-03-09T16:20:40Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![joschi](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/joschi/32/44946_2.png) [@joschi](https://discuss.elastic.co/u/joschi)\
**Post date:** [March 10, 2022, 7:52am UTC](https://discuss.elastic.co/t/default-indicesoptions-in-searchrequest-and-disable-specific-deprecation-warnings/299242/3 "2022-03-10T07:52:47Z")

</div>

@DavidTurner Yes, we're using the Java High Level REST Client in version 7.16.3.

I would _not_ have expected that it's causing the deprecation warning without any possibility whatsoever to disable it, either by not sending the deprecated parameter or by disabling the warning message.

So out of the box you cannot use Elasticsearch 7.16.x or later with the Java High Level REST Client _without_ producing the deprecation warning, which makes up ~95% of log messages in our ES clusters. 🤯

This forces us to do a big bang migration to the new [Java client](https://github.com/elastic/elasticsearch-java) (which has hopefully matured enough by now) without giving the option to do a gradual migration, which we planned originally.  
I found that a bit surprising for a "minor version" upgrade (7.15 -\> 7.16). ☹

For reference, here's a pull request of a colleague of mine to avoid the deprecation warning without breaking backward compatibility in ES 7.x:

> <https://github.com/elastic/elasticsearch/pull/84827>
>
> \# Why
> 
> When setting indices options in the (now deprecated) \`RestHighLevelClie…nt\`, even if we do not explicitly set \`ignore\_throttled\`, the client sends the \`ignore\_throttled\` parameter to the server. Since 7.16, this parameter is deprecated, and so the server sends back a warning header which is unconditionally logged.
> 
> This is extremely spammy in our environments because we usually set non-deprecated indices options, and so all of our requests are sending (without our control) the \`ignore\_throttled\` parameter.
> 
> The \`RestHighLevelClient\` should not send the deprecated \`ignore\_throttled\` parameter unless it is set to the non default value of \`false\`.
> 
> \# What
> 
> This PR changes the \`RequestConverters\` to only send the \`ignore\_throttled\` parameter when it is set to a non-default value. Otherwise it does not include it.
> 
> \# Other notes
> 
> Happy to submit this against \`master\` however this should most definitely be available in the version where the deprecation was introduced (7.16) so I targeted that branch.

Maybe you could consider merging it for Elasticsearch 7.16.4 and onwards.

---

_[View the full topic](https://discuss.elastic.co/t/default-indicesoptions-in-searchrequest-and-disable-specific-deprecation-warnings/299242)._