<p dir="auto">The <code class="notranslate">_msearch</code> API currently doesn't allow you to specify a timeout parameter in the header of each request.</p>
<p dir="auto">This is problematic given that long running queries can easily swamp an ES node.</p>
<p dir="auto">Recommend that we add timeout to the API which is specified per request in milliseconds for consistency with the timeout parameter for the <code class="notranslate">search</code> API:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="{&quot;timeout&quot;: 100}
{&quot;query&quot;: ...}
{&quot;timeout&quot;: 50}
{&quot;query&quot;: ...}
..."><pre class="notranslate"><code class="notranslate">{"timeout": 100}
{"query": ...}
{"timeout": 50}
{"query": ...}
...
</code></pre></div>
<p dir="auto">Happy to contribute here but not sure where to start.</p>
<p dir="auto">Thoughts?</p>
<p dir="auto">The <code class="notranslate">_msearch</code> API doesn't accept the same header parameters than <code class="notranslate">_search</code>'s query parameters.<br>
For instance <code class="notranslate">version</code> is both valid in the search body and query parameters for <code class="notranslate">_search</code>, but is ignored in the query parameters and header in <code class="notranslate">_msearch</code>.</p>
<p dir="auto"><code class="notranslate">MultiSearchRequest.add()</code> should rely on <code class="notranslate">RestSearchAction.parseSearchSource()</code> or even <code class="notranslate">RestSearchAction.parseSearchRequest()</code> to parse the subrequests, for maximum compatibility.</p>
<p dir="auto">IMHO, a clean bulk API should use the header parameters as query parameters on the target endpoint, which would imply that they keep in sync no matter the code changes in the target endpoints.</p>