`es search --input-file` drops top-level `aggs` (and any unrecognised key) without an error
I maintainer di solito rispondono entro 1 giorno
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 55/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- elasticsearch, typescript
- Ambito
- cli
Direzione di ricerca
Start by reproducing with the body.json snippet and comparing the CLI result with the direct Elasticsearch call. Then read src/es/request-builder.ts:163-169 and src/lib/json-schema-args.ts:193-206 to see how only schema-declared keys are copied, and check src/lib/ajv-validate.ts for validation behavior. Decide between forwarding and rejecting unknown top-level keys, and handle aggs as an alias of aggregations; done means aggs works and a misspelt key no longer silently returns unfiltered results, with tests for both.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Related to elastic/cli#803
Summary
The ES request builder rebuilds the request body from the keys declared in the command's schema. Any other top-level key in --input-file is dropped before the request is sent. The command exits 0 and prints no warning.
The most common case is aggs. Elasticsearch accepts both aggs and aggregations, and most docs and examples use aggs. The search schema declares only aggregations, so a body written with aggs returns hits and no aggregations key.
A misspelt key fails the same way. Elasticsearch would answer 400 to a misspelt query; the CLI sends the request without it and returns unfiltered results.
Reproduction (v0.7.0, also unchanged on main at fd3359d)
cat > body.json <<'JSON'
{"size":0,"aggs":{"by_day":{"date_histogram":{"field":"@timestamp","calendar_interval":"day"}}}}
JSON
elastic es search --index my-index --input-file body.json | jq 'has("aggregations")'
# false (exit 0, empty stderr)
curl -s -H "Authorization: ApiKey $KEY" -H 'Content-Type: application/json' \
"$ES/my-index/_search" -d @body.json | jq 'has("aggregations")'
# true
jq '.aggregations=.aggs | del(.aggs)' body.json | elastic es search --index my-index --input-file - | jq 'has("aggregations")'
# true
Misspelt key:
echo '{"qeury":{"term":{"event.action":"no-such-value"}}}' | elastic es count --index my-index --input-file -
# returns the full index count, exit 0
# Elasticsearch directly: 400 "request does not support [qeury]"
Scope observed
| Command | Unknown top-level key |
|---|---|
es search |
dropped |
es count |
dropped |
es esql query |
dropped |
es async-search submit |
dropped (checked against a local capture server: body keys ["query","size"]) |
es msearch |
bodies inside searches pass through, including aggs |
kb … |
forwarded (src/kb/request-builder.ts) |
Nested keys are not affected: sub-aggregations under aggregations keep aggs.
Mechanism
src/es/request-builder.ts:163-169copies only schema-derived arguments (src/lib/json-schema-args.ts:193-206) into a new body. Keys outside the schema never reach it.search.request.jsonin@elastic/schemas0.10.0 declaresproperties.aggregationsbut noaggs.- AJV does not remove the key (
src/lib/ajv-validate.tssets noremoveAdditional), so--no-validatemakes no difference.
Conflicts with AGENTS.md
The input rules in AGENTS.md ("Command Authoring Requirements" → "Input") say:
Reject unknown keys: Input with undefined keys MUST produce a validation error naming the unknown field(s). Silent stripping is not acceptable.
For ES commands, an unknown top-level key is neither rejected nor sent. Applied as written, that rule would make aggs a validation error, which still breaks the most common Elasticsearch body shape. Accepting aggs as an alias of aggregations, and rejecting other unknown keys, satisfies both.
Root cause
Two layers, both needed:
@elastic/schemasdoesn't carry the spec's alias. The specification marksaggregationswith@aliases aggs(SearchRequest.tsL414-L419). The JSON Schema output drops it, soaggsreaches the CLI as an unknown key. Reported upstream: elastic/schemas-js#125.- The ES request builder drops unknown keys instead of rejecting them (see Mechanism). This is a CLI defect independent of the schemas: a misspelt
queryreturns unfiltered results with exit 0.
If the upstream fix emits aggs as a declared property, the CLI picks it up with no change. If it adds an annotation instead, the CLI must read that annotation. Fixing (2) turns any remaining unknown key into a validation error, as AGENTS.md requires.
Expected
Either option would avoid wrong results with exit 0:
- Forward unknown top-level body keys, as the Kibana builder does, and let Elasticsearch accept or reject them. At minimum, accept
aggsas an alias ofaggregations. - Or fail (or warn on stderr) when
--input-filecontains a top-level key the command will not send.
Related
- elastic/cli#170 and elastic/cli#223: rejection of unknown fields, fixed by moving to passthrough schemas. This report is the opposite symptom: no rejection, the key is silently omitted.
- elastic/cli#699: malformed JSON passing validation. It mentions
aggs, but not this omission. - elastic/cli#786: request-routing unification. It keeps service-specific behaviour, so it doesn't appear to change this.
- Lingua principale
- TypeScript
- Stelle
- 53
- Fork
- 28
- Merge medio
- 23h 41m
- PR unite (30g)
- 44
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di elastic/cli
-
tracking
Difficoltà 2/5 1-3 ore Idoneità per principianti 77/100
I maintainer di solito rispondono entro 1 giorno
-
feat: ship skills/elastic/SKILL.md for agent invocationForse già presa @onatozmenn l’ha presa 31 giorni fa. Apertaenhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
elastic/cli#628 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
elastic/cli#617 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 63/100
I maintainer di solito rispondono entro 1 giorno
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
gnosis/gnosis_vpn#661 ·
I maintainer di solito rispondono entro 1 giorno
-
content-freshness: staleOwnedContent doc comments still say 'complete receipt' (follow-up to #7912)Apertatriage:bug-verified
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 92/100
I maintainer di solito rispondono entro 1 giorno
-
fix: reject sourceStorage/packagedStorage bucket that differs from the stack default (fail loud)Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
Eyevinn/open-videocore#1300 ·
I maintainer di solito rispondono entro 1 giorno
-
nextjs-tracking
Difficoltà 2/5 1-3 ore Idoneità per principianti 67/100
cloudflare/vinext#4390 ·
I maintainer di solito rispondono entro 1 giorno
-
kind/bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
kubernetes-sigs/headlamp#8175 ·
I maintainer di solito rispondono entro 2 giorni