imbajin commented on PR #2994:
URL: https://github.com/apache/hugegraph/pull/2994#issuecomment-4778893202
I took another look at the latest head and I don't think this should be
treated as a generic `pd-store` timeout.
Current head: `18fe87f3c9a4e1a455340944ab5c66f175ce7f65`
Current PR state:
```text
reviewDecision: APPROVED
mergeable: MERGEABLE
mergeStateStatus: UNSTABLE
HugeGraph-PD & Store & Hstore CI
├─ struct: SUCCESS
├─ pd: SUCCESS 06:00:35 -> 06:09:30
├─ store: SUCCESS 06:00:29 -> 06:14:10
└─ hstore: CANCELLED 06:00:35 -> 12:00:50
└─ Run core test: 06:05:23 -> 12:00:48
Other visible red check:
└─ codecov/project: FAILURE
```
So the failing GitHub Actions job is specifically `hstore` in `HugeGraph-PD
& Store & Hstore CI`. `pd` and `store` passed on this run.
Why I don't think this is just a slow runner:
```text
Recent successful HStore runs
run 27693769986
└─ hstore total: about 24m26s
Run core test: about 10m21s
run 27893737780
└─ hstore total: about 24m41s
Run core test: about 10m50s
run 28014295081
└─ hstore total: about 24m26s
Run core test: about 10m29s
PR #2994 latest run 27739968315
└─ hstore total: about 6h, then cancelled
Run core test: about 5h55m, then cancelled
```
The job was not stuck in dependency download, compile, or startup. It
entered `Run core test` and then ran until GitHub cancelled the job at the
6-hour boundary.
The most relevant log evidence I found is the last useful stack before
cancellation:
```text
VertexCoreTest.testQueryInPageWithoutCapacity
-> IteratorUtils.count(...)
-> PageEntryIterator.hasNext/fetch
-> QueryList.fetchNext
-> GraphIndexTransaction.doIndexQueryOnce
-> HStore iterator / KvPageScanner close
```
There is also a Netty `ByteBuf.release()` leak report around that path, but
I would treat that as a symptom exposed during iterator close/cleanup, not as
the primary explanation for why the core test never finishes.
The suspicious overlap with this PR is high:
```text
PR changes
├─ QueryList.java
│ └─ paged index result fetch now keeps input order
├─ GraphIndexTransaction.java
│ └─ index scan filtering / matched-index read path changed
├─ HstoreTable.java
│ └─ adds RangeIndexEntryIterator for range-index paging
└─ VertexCoreTest.java
└─ affected paging/index test area
Failed runtime path
└─ hstore core test
└─ VertexCoreTest.testQueryInPageWithoutCapacity
└─ paged index query
└─ QueryList / GraphIndexTransaction / HStore iterator
```
My current hypothesis is that the HStore range-index paging
cursor/page-state is not advancing correctly for this path. `PageEntryIterator`
depends on the page returned by the lower layer to move forward. If the HStore
range-index iterator returns a page state that points back to the same
range/entry, the outer paging loop can repeatedly fetch the same page/range and
keep the core test running until the CI timeout.
Conceptually:
```text
g.V().has("age", 30).has("~page", "").limit(-1)
|
v
GraphIndexTransaction.doIndexQueryOnce()
|
v
HStore range-index scan
|
v
RangeIndexEntryIterator.pageState()
|
v
PageEntryIterator.fetch()
|
+-- if page state does not move monotonically
fetch repeats / iterator cleanup repeats / test never completes
```
Given that this PR directly changes the HStore/query paging area, I don't
think a rerun alone is enough evidence unless the same HStore range-index
paging path is proven stable. I would not merge this head as-is. Please fix or
revert the HStore range-index paging part, or move that piece into a dedicated
follow-up where the storage-client page-state contract can be handled
explicitly.
At minimum, I think we need a targeted regression check around:
```text
HStore + range/index query + paging + no capacity / large limit
```
The Codecov project failure is still visible too, but the `hstore` timeout
is the more important blocker because it overlaps with the changed behavior
rather than looking like an unrelated external check.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
