The gateway accepted min_score, terminate_after, and per-search timeout fields but did not apply them. That is more dangerous than a clear unsupported-feature response: a caller could ask to remove low-scoring hits, stop collection early, or return within a deadline and instead receive an ordinary complete page.

Separate ephemeral-container probes exercised Elasticsearch 9.5.5 and OpenSearch 3.9.0 with the same one-shard, three-document corpus. min_score: 2 removed all three match_all hits on both engines. terminate_after: 1 returned one hit with terminated_early: true on both, but Elasticsearch reported a total of three while OpenSearch reported one. Both engines accepted timeout: "1s", returned timed_out: false for this small request, and rejected the invalid value "banana" with HTTP 400. The sanitized request and response evidence records the versions, images, requests, and observed fields.

The gateway now rejects all three controls before index lookup or Qdrant access. Supporting them requires explicit decisions about score comparability, partial-result behavior, and the Elasticsearch/OpenSearch early-termination total difference; silently choosing one engine’s shape would misrepresent the other. The focused regression includes valid-looking values for every field and proves that none reaches the mocked Qdrant endpoint:

cargo test invalid_search_options_fail_before_qdrant_work

This is request/response evidence, not a latency benchmark. The one-second timeout did not expire, and the small one-shard corpus does not characterize distributed early termination. Existing searches that omit these fields are unchanged; _msearch inherits the same fail-closed validation for each query.