Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[BUG] PPL FIRST/LAST/TAKE appear to ignore a preceding sort on multi-shard indices

Aperta
  • Qualcosa non va?
#5,716 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
55/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
java
Ambito
databases, distributed-systems

Direzione di ricerca

Inizia con i test esistenti di CalciteAliasFieldAggregationIT denominati testFirstWithAliasField, testLastWithAliasField e testTakeWithAliasField, quindi segui la generazione di FIRST, LAST e TAKE top_hits descritta nell’issue. Confronta l’esecuzione con un solo shard e con più shard, e verifica che venga rispettato l’ordinamento PPL precedente; i test dovrebbero avere esito positivo con i valori attesi, chiarendo la semantica di TAKE se il suo ordinamento rimane non specificato.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug
What is the bug?

On a multi-shard index, FIRST(), LAST(), and TAKE() appear not to preserve a preceding PPL sort.

The same query returns the expected values on a one-shard index. earliest() and latest() remain correct over the same documents.

Reproduction

Create identical one-shard and five-shard indices:

for SH in 1 5; do
  curl -XDELETE "localhost:9200/rp_$SH"
  curl -XPUT "localhost:9200/rp_$SH" -H 'Content-Type: application/json' -d "{
    \"settings\":{\"number_of_shards\":$SH,\"number_of_replicas\":0},
    \"mappings\":{\"properties\":{\"@timestamp\":{\"type\":\"date\"},\"txt\":{\"type\":\"keyword\"}}}}
  }"
  curl -XPOST "localhost:9200/rp_$SH/_bulk?refresh=true" \
    -H 'Content-Type: application/x-ndjson' --data-binary '
{"index":{"_id":"1"}}
{"@timestamp":"2024-01-01T10:00:00Z","txt":"a"}
{"index":{"_id":"2"}}
{"@timestamp":"2024-01-02T10:00:00Z","txt":"b"}
{"index":{"_id":"3"}}
{"@timestamp":"2024-01-03T10:00:00Z","txt":"c"}
'
done

Run against each index:

source=rp_N
| sort @timestamp
| stats FIRST(@timestamp), LAST(@timestamp), TAKE(@timestamp, 2),
        earliest(@timestamp), latest(@timestamp)

Observed results:

1 shard: FIRST=01-01  LAST=01-03  TAKE=[01-01,01-02]  earliest=01-01  latest=01-03
5 shards: FIRST=01-03  LAST=01-03  TAKE=[01-03,01-02]  earliest=01-01  latest=01-03

The five-shard result is repeatable, but does not follow the explicit timestamp ordering.

Existing integration-test failures

The existing alias-field tests show the same issue with different shard placement:

CalciteAliasFieldAggregationIT::testFirstWithAliasField
query:    source=%s | sort @timestamp | stats FIRST(@timestamp)
expected: 2024-01-01 10:00:00
actual:   2024-01-02 10:00:00

CalciteAliasFieldAggregationIT::testLastWithAliasField
query:    source=%s | sort @timestamp | stats LAST(@timestamp)
expected: 2024-01-03 10:00:00
actual:   2024-01-02 10:00:00

CalciteAliasFieldAggregationIT::testTakeWithAliasField
query:    source=%s | sort @timestamp | stats TAKE(@timestamp, 2)
expected: [2024-01-01, 2024-01-02]
actual:   [2024-01-01, 2024-01-03]
Expected behavior

After sort @timestamp, FIRST() and LAST() should return the first and last values in that order, independent of shard count.

For TAKE(), the documentation currently says result order is not guaranteed. However, it would be useful to clarify whether the preceding sort should at least determine which values are selected.

Possible implementation clue

This may be related to how these aggregations are pushed down as top_hits:

FIRST -> createTopHitsBuilder(..., 1,    true, false, null,   null)
TAKE  -> createTopHitsBuilder(..., size, true, false, null,   null)
LAST  -> createTopHitsBuilder(..., 1,    true, true,  "_doc", SortOrder.DESC)

FIRST and TAKE do not pass a sort key, while LAST uses _doc, which is not a globally comparable document-order key across shards. The preceding PPL collation may therefore not reach the generated top_hits aggregation. This is only a possible explanation and needs maintainer confirmation.

This also appears consistent with the limitation noted in #5537: adding an explicit sort does not stabilize stats first()/last()/take() on multi-shard execution.

Environment
  • OpenSearch 3.7.0
  • opensearch-sql plugin
  • Single node
  • One versus five primary shards
  • No replicas
Lingua principale
Java
Stelle
175
Fork
233
Merge medio
2g 19h
PR unite (30g)
37

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di opensearch-project/sql

Tutte le issue di opensearch-project/sql

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.