[Bug] Store dedup iterators drop rows at query batch boundaries

已关闭

#3,415 创建于 2026年10月27日 0 条评论 0 个 reaction 已指派 0 人在 GitHub 查看

维护者通常 1 天内回复

已经有一个关联 PR 被合并了。

#3424 来自 @vaidikgarg-bit —— 已合并

评估

难度: 3/5
预计耗时: 1-2 天
新手友好度: 84/100

Issue 类型: 缺陷
描述清晰度: 描述清楚
活跃度: 活跃
技术栈: java
领域: backend, databases

调研方向

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: master at 9a8f066e6 (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 checks count >= batchSize, so at a full batch it breaks after a probe without calling next();
after the loop it calls itr.hasNext() again to set finish.

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() returns null instead of throwing NoSuchElementException when 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
派生: 642
平均合并: 1 天 7 小时
30 天内合并 PR: 122

环境准备

没有 Dockerfile 或 Docker Compose 文件
有 Pull Request 模板
阅读贡献指南

从这里开始

先读完整个 Issue，再读项目的贡献指南。
在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
Fork 仓库，在一个分支上完成修改。
提交 Pull Request，并在描述里引用这个 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 人 · 2026年9月23日创建

维护者通常 1 天内回复
[Bug] Gremlin sandbox blocks HStore gRPC allocator configuration reads
未关闭
- 哪里不对？
难度 4/5 3-5 天新手友好度 25/100

apache/hugegraph#3412 · 2026年10月26日创建

维护者通常 1 天内回复
[Bug] PD KV keys share one namespace with TTL markers and locks, so the TTL cleanup deletes a client key named like a marker
未关闭
- 哪里不对？
难度 4/5 3-5 天新手友好度 55/100

apache/hugegraph#3392 · 2026年10月22日创建

维护者通常 1 天内回复
[Bug] PD gRPC workers stay held while the leader has no quorum: KV writes, id reads and KV reads wait on the shared hg-grpc pool
未关闭
- 哪里不对？
难度 4/5 3-5 天新手友好度 35/100

apache/hugegraph#3389 · 2026年10月21日创建

维护者通常 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

apache/hugegraph#3378 · 2026年10月20日创建

维护者通常 1 天内回复

查看 apache/hugegraph 的全部 Issue

相似的 Issue

PropertyEditorRegistrySupport.createDefaultEditors is not thread-safe when a registry is shared across threads
未关闭
- 哪里不对？
status: waiting-for-triage

难度 2/5 1-3 小时新手友好度 78/100

spring-projects/spring-framework#37614 · 2026年10月31日创建

维护者通常 1 天内回复
[Spring Cloud Azure] Improve Javadoc and startup guidance for allowed-group-names vs allowed-group-ids in AadAuthenticationProperties
未关闭
- 哪里不对？
azure-spring azure-spring-aad Client

难度 2/5 1-3 小时新手友好度 72/100

Azure/azure-sdk-for-java#51046 · 1 个 reaction · 2026年10月30日创建

维护者通常 1 天内回复
helm-knative-apply.sh fails with Helm 4
可能已有人在做关联的 PR 仍在进行中或已合并。未关闭
- 哪里不对？
area: triage theme: undefined

难度 2/5 1-3 小时新手友好度 85/100

jhipster/generator-jhipster#35895 · 2026年10月30日创建

维护者通常 1 天内回复
Renderer.getFrameInfoHistory aborts the process on minified Android release builds (FrameInfo fields removed by R8)
未关闭
- 哪里不对？
难度 2/5 1-3 小时新手友好度 78/100

google/filament#10756 · 2026年10月30日创建

维护者通常 1 天内回复
Forge tests red on master: test_prepare chunk-resume fixture writes an exhaust report resolve_chunk cannot parse
未关闭
- 哪里不对？
难度 2/5 1-3 小时新手友好度 85/100

oracle/graalvm-reachability-metadata#11659 · 2026年10月30日创建

维护者通常 1 天内回复

更多 Java Issue

[Bug] Store dedup iterators drop rows at query batch boundaries

哪里不对？

评估

调研方向

描述

Bug Type (问题类型)

Environment (环境信息)

Expected & Actual behavior (期望与实际表现)

环境准备

从这里开始

apache/hugegraph 的其他 Issue

哪里不对？

哪里不对？

哪里不对？

哪里不对？

哪里不对？

相似的 Issue

哪里不对？

哪里不对？

哪里不对？

哪里不对？

哪里不对？

把新 issue 发到你的邮箱