[thweetkomputer]

Grouped ZRANDMEMBER now samples ranks before taking IS and S on the selected ordered pages; ZSCAN takes S on the member leaves covering its cursor/count window. Both revalidate their plan after waits and retain a common logical cut through reply construction. A changed random population falls back once to key S. Scan keeps its full ordered-page compatibility path when persisted and public cursor seeds differ.

Validation: Debug builds and nine focused E2E tests pass, covering selective read/write overlap, conflict wait/wakeup, random semantics and OOM, scan cursor/mutation/promotion/recovery behavior, and the existing range concurrency cases.

Based directly on main; this PR contains only random and scan reads.

Summary by CodeRabbit

• Improvements
  • ZRANDMEMBER and ZSCAN can now run alongside updates to unrelated sorted-set groups, while preserving consistent results for the data they read.
  • Concurrent reads remain protected when updates affect the same data being read.

[coderabbitai]

Caution

Review failed

The pull request is closed.

Walkthrough

Grouped sorted-set reads now route eligible ZRANDMEMBER and ZSCAN operations through concurrent page reads. The read path locks selected pages or member-index leaves, validates read state, and refreshes data under those locks. Architecture documentation and concurrency and recovery tests cover the behavior.

Changes

Grouped sorted-set sampling reads

Layer / File(s)	Summary
Read eligibility and lock planning src/storage/engine/sorted_set_api.cpp, src/storage/engine/impl.h, src/storage/engine/grouped/zset.cpp	Eligible random and scan operations can use the concurrent read path. The path prepares random ranks and selects grouped lock IDs for sampled ordered pages or scan-window member leaves.
Locked reads and validation src/storage/engine/grouped/zset.cpp, src/storage/engine/impl.h, docs/architecture/09-grouped-collections.md, tests/grouped/zset_write_e2e_test.cpp	Random reads and scans refresh data under selected locks and validate population and routing. Documentation describes the lock windows, and tests cover concurrent writes, returned values, and recovery.

Estimated code review effort: 3 (Moderate) | ~25 minutes

Change: Feature

Possibly related PRs

• eloqdata/lavik#408: Adds the member-leaf ZSCAN path and different-seed fallback that this change extends with locking.
• eloqdata/lavik#431: Adds prepared page publication and count merging; this change validates reads while unrelated group publications can proceed.
• eloqdata/lavik#432: Adds IX point writes and locked-group refresh used by these reads.

Suggested reviewers: liunyl

Merge Risk: Low · up to f7c4a

The change is mergeable with bounded owner awareness: uncommon storage API usage can produce scan failures during concurrent writes or false out-of-memory errors before memory-limit initialization. Normal server initialization avoids the latter. Both localized fixes are recommended, alongside stronger revalidation coverage.

- [ ] Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

• X
• Mastodon
• Reddit
• LinkedIn

_{A rabbit checks the pages with care
And holds the leaves that fall in range
A distant group can still make tracks
The scores stay true through read and write
Then home I hop, with locks in tow}