[Bug] Store dedup iterators drop rows at query batch boundaries
メンテナーはふだん 1 日以内に返信
関連するプルリクエストがすでにマージされています。
- #3424 @vaidikgarg-bit による — マージ済み
評価
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 初心者へのやさしさ
- 84/100
調査の方向性
Start with AggregativeQueryObserver.readBatchData and the three iterators in BusinessHandlerImpl: MapLimitIterator, InAccurateUnionFilterIterator, and InAccurateIntersectionIterator. Read FilterIteratorContractTest, especially assertSingleRecordBatches, then add these iterators to the contract checks. Done means batch boundaries preserve all distinct rows, close prevents further source probes, and MapLimitIterator.next() throws NoSuchElementException when exhausted.
索引モデルが issue の本文から書いたものです。
説明
Bug Type (问题类型)
logic (逻辑设计问题)
Environment (环境信息)
- Server Version:
masterat9a8f066e6(1.8.0-SNAPSHOT) - Backend: HStore (Store query service,
AggregativeQueryObserver) - JDK 17
Expected & Actual behavior (期望与实际表现)
A Store query with dedup_option set to DEDUP or LIMIT_DEDUP (or PRECISE_DEDUP with a limit) should return every distinct row once, regardless of how the results are split into batches. Instead, rows go missing at each batch boundary.
AggregativeQueryObserver.readBatchData probes the iterator more than once per row:
- the read loop calls
itr.hasNext()before it checkscount >= batchSize, so at a full batch it breaks after a probe without callingnext(); - after the loop it calls
itr.hasNext()again to setfinish.
UnionFilterIterator and IntersectionFilterIterator keep a pending element across repeated probes (#3395 added FilterIteratorContractTest for that). The three dedup iterators BusinessHandlerImpl builds for these options do not:
MapLimitIterator(LIMIT_DEDUP, and PRECISE_DEDUP with a limit)InAccurateUnionFilterIterator(DEDUP)InAccurateIntersectionIterator(multi-param index intersection)
Each hasNext() starts with current = null and pulls the next unseen row from the source. The row found by the previous probe is already in the dedup set or bitmap, so it is never returned.
Reproduction: add the three iterators to FilterIteratorContractTest.assertSingleRecordBatches (batch size 1, three distinct keys). On master each returns 2 records instead of 3.
The same tests show the iterators also miss the rest of that contract:
- after
close()they still probe the closed source; MapLimitIterator.next()returnsnullinstead of throwingNoSuchElementExceptionwhen nothing is left.
Only a gRPC client that sets dedup_option reaches these paths today, since StoreQueryParam fixes it to NONE.
I found this while reading the query path around #3408 and would like to work on it: keep the pending element across probes, clear it in next(), and make close() stop further probing, with the three iterators added to FilterIteratorContractTest.
- 主要言語
- Java
- スター
- 3.2k
- フォーク
- 645
- 平均マージ
- 1日 7時間
- マージ済み PR（30日）
- 122
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
apache/hugegraph のほかの issue
-
[Bug] PD task REST: balanceLeaders throws a bare HTTP 500 during the balance-shard window, and task responses cannot be told apart from a no-op or a follower answer対応中かも @pallavithegod が 11 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
apache/hugegraph#3231 · コメント 2 件 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
-
[Bug] Gremlin sandbox blocks HStore gRPC allocator configuration reads対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 4/5 3〜5日 初心者へのやさしさ 25/100
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 55/100
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
メンテナーはふだん 1 日以内に返信
-
[Bug] PD TTL cleanup deletes the marker-shaped name instead of the expired key, so expired values stay in the store until read対応中かも @bitflicker64 が 10 日前に担当しました。 オープン
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
メンテナーはふだん 1 日以内に返信
apache/hugegraph の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
quarkusio/quarkus-agent-mcp#302 ·
メンテナーはふだん 2 日以内に返信
-
build
難易度 1/5 1時間未満 初心者へのやさしさ 85/100
MetricsHub/metricshub-community#1472 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信
-
IdentityArrayObjectSet iterator remove may throw ArrayIndexOutOfBoundsException対応中かも @jiteshkhatri11 が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
javapathfinder/jpf-core#660 · コメント 1 件 ·