The gateway accepted search bodies containing script_fields, did not execute the scripts, and returned ordinary hits without the requested fields object. That is a false success for clients that calculate display values or other per-hit data at search time.

A focused probe used the same one-document mapping, script, and request against separate Elasticsearch 8.15.0 and OpenSearch 3.9.0 containers. With _source: false, both engines evaluated doc["price"].value + params.increment and returned fields.next_price: [43]. Both omitted fields when script_fields was an empty object. The engines document this behavior independently in the Elasticsearch Search API and OpenSearch script-field guide.

The sanitized request and response evidence records the images, versions, fixture, selected hit fields, reproduction sequence, and limitations. This establishes request/response behavior for the two recorded versions; it is not a script-performance or sandbox-security benchmark.

The gateway now rejects every non-empty script_fields object before index lookup or Qdrant access, including in each _msearch subrequest. An empty object remains an accepted no-op, and malformed non-object values fail validation. Searches that omit script_fields are unchanged.

cargo test invalid_search_options_fail_before_qdrant_work

Native support would require a deliberate scripting language, execution limits, field-access semantics, error contract, and security model. Copying a guessed value from _source would not execute the requested program and would be less honest than a structured compatibility error.