fix(api): one script-guard definition for every search entry point - #124

PR #115 closed a real bypass — /_msearch skipped the request-time script guard entirely — but it closed it with a different check than _search uses, and that asymmetry is a live defect on main.

build_search_request runs the guard on six specific fields (query, rescore, sort, script_fields, runtime_mappings, aggs). The _msearch, _search/template and _msearch/template guards ran it on the whole request body. So _msearch became stricter than _search: an over-limit script under any unrelated key returned 400 where the identical search returned 200.

Measured with a 45-case router probe run against both commits, fingerprinting status, hits.total, hit ids, agg keys and error type at all four entry points: 12 bodies on main where _search answers 200 and the three raw paths answer 400.

The fix

One definition. enum GuardedField names the six fields once; in_raw_body projects it onto a raw JSON body and in_search_body onto the typed EsSearchBody. Both matches are exhaustive, so a field cannot be guarded on one path and skipped on the other.

The aggs/aggregations pair is a single value resolved the way the executor resolves it. This matters because an earlier attempt at this listed both spellings as independent keys, which produced a new asymmetry: a body with an ordinary aggs and an over-limit script under aggregations got 200 from _search and 400 from _msearch, even though neither endpoint executes that value — parse_request also does obj.get("aggs").or_else(|| obj.get("aggregations")).

The precedence rule is key-name, not document order. serde_json preserves order workspace-wide, so this is observable: {"aggregations": <over-limit>, "aggs": <ordinary>} answers 200 everywhere and executes the aggs value despite it being written second.

Behaviour change

On _msearch, _search/template and _msearch/template, an over-limit script under any key other than the six guarded ones goes 400 → 200. Beyond highlight, suggest, docvalue_fields and collapse.inner_hits, that was measured on post_filter, _source, fields, ext, stored_fields, pit, indices_boost and a top-level inner_hits object.

None of these is a script sink — parse_request reads only query, sort, aggs and script_fields among them — so nothing executes and the direction is the ES-compatible one. _search itself is unchanged: every status in the probe table is identical before and after on the _search column.

Two bodies now disagree between the typed and raw paths where main happened to agree (a knn.filter carrying a script, and {"aggs": null, "aggregations": <over-limit>}). Main's agreement was accidental — the whole-body walk 400'd everything — and no script executes on the raw paths in either case.

The #115 bypass stays closed

Re-verified independently with a 240,531-byte three-hostile-item _msearch body: still rejected per-item.

A gap verification found, now closed

Adding a GuardedField variant was already a compile error. Removing one was not, and that is the direction that reopens #115. Every test over the guarded set iterates ALL, so they prove the guard covers whatever ALL holds, not six specific fields — measured, deleting Self::Rescore left all 129 tests green while an 80,001-byte rescore script went 400 → 200 on every entry point.

const _: () = assert!(GuardedField::ALL.len() == 6) makes that a build failure. Verified by mutation: evaluation panicked: assertion failed: GuardedField::ALL.len() == 6.

Unrelated flake worth knowing about

es_compat::scripted_update_publication_tests::concurrent_scripted_update_by_query_preserves_every_increment fails roughly 1 in 60 full-suite runs on both this branch and main, and 0 in 60 targeted runs, so it only trips under suite concurrency. Introduced by dc24130; this diff does not touch it. Flagging so it is not misattributed to whichever PR is in flight when it eventually turns CI red.