# Compound sort with \`missing: "\_last"\` silently drops/substitutes hits when every document ties on the leading field

**URL:** <https://discuss.elastic.co/t/compound-sort-with-missing-last-silently-drops-substitutes-hits-when-every-document-ties-on-the-leading-field/387834>\
**Category:** Elasticsearch\
**Created:** [July 8, 2026, 3:26am UTC](https://discuss.elastic.co/t/compound-sort-with-missing-last-silently-drops-substitutes-hits-when-every-document-ties-on-the-leading-field/387834 "2026-07-08T03:26:18Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Kent-Kuan](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kent-kuan/32/147823_2.png) [@Kent-Kuan](https://discuss.elastic.co/u/Kent-Kuan)\
**Post date:** [July 8, 2026, 3:26am UTC](https://discuss.elastic.co/t/compound-sort-with-missing-last-silently-drops-substitutes-hits-when-every-document-ties-on-the-leading-field/387834/1 "2026-07-08T03:26:18Z")

</div>

We found a correctness bug: sorting by two fields where the leading field is missing on every matching document returns a wrong, incomplete top-N — even though the result should be mathematically identical to sorting by the second field alone.

Sort used:

```auto
"sort": [
  { "markedTime": { "order": "desc", "missing": "_last" } },
  { "createdTime": { "order": "desc" } }
]

```

markedTime is missing on 100% of matching docs (confirmed via exists aggregation, doc\_count: 0). So this should return the same result as sorting by createdTime alone. It doesn't — over half the true top-20 is missing, replaced by lower-ranked docs. No error, no timed\_out, no shard failures.

Minimal repro:

- 2 date-partitioned indices, 5 shards each, no replicas
- 3000 docs/index, distinct createdTime, markedTime never set on any doc

Query A (baseline): `sort: [{ "createdTime": { "order": "desc" } }]`  
Query B (bug): `sort: [{ "markedTime": { "order": "desc", "missing": "\_last" } }, { "createdTime": { "order": "desc" } }]`  
Query C (workaround): same as B but `"missing": "-9223372036854775808"` (the literal value \_last resolves to) instead of the keyword

Result: A and C are identical and correct. B diverges — only 4 of 20 hits actually belong in the true top-20.

Repeating B 3x against static data:

- 8.15.3: same wrong result every time (deterministic)
- 9.4.3: a different wrong result every time (non-deterministic)

Since B and C resolve to the exact same internal sort value for missing docs, this isn't about the missing value itself — it's the "\_last"/"\_first" keyword taking a different (buggy) code path than an explicit literal value, likely in the shard/segment skip-optimization that decides whether a shard can be skipped based on the sort field's real value range, without accounting for shards holding only missing-value documents.

Workaround: use an explicit missing value (e.g. "missing": "0") instead of "\_last"/"\_first". Confirmed correct on both versions tested.

Is this a known issue, or are we misusing missing:"\_last" with compound sort?