Adjust hash partition mapping in Eloq submodules

[thweetkomputer]

Summary

• bump eloq/store_handler to use the lower 10 hash bits for partition IDs and adopt std::ranges sort checks
• expand the store handler’s .gitignore and fix the pool resize cast for clarity
• sync eloq/tx_service to drop a stray blank line in the hash-partition data sync implementation

Summary by CodeRabbit

• Chores
  • Updated internal submodule references for storage and transaction components to newer revisions.
  • No changes to user-facing functionality, public APIs, behavior, or error handling.
  • No expected impact on performance or stability.
  • Routine dependency maintenance to keep internal modules current.

[coderabbitai]

Walkthrough

Updated git submodule pointers for eloq modules at src/mongo/db/modules/eloq/store_handler and src/mongo/db/modules/eloq/tx_service. Only submodule revision references changed; no source, API, or control-flow modifications.

Changes

Cohort / File(s)	Summary of Changes
Eloq submodule update — store_handler src/mongo/db/modules/eloq/store_handler	Update submodule pointer: 7ca9d319d3d24a7185c3594b4af2c9ed74093774 → e5975fbd1609a16a12e91aae567206d1b83283dc
Eloq submodule update — tx_service src/mongo/db/modules/eloq/tx_service	Update submodule pointer: 48e5c862f36a0e5096c7e1bae42a1790b7c0fba7 → 16f3cf1d6aabb763b1e8d2a71f0b06385a4631e3

Sequence Diagram(s)

No sequence diagrams included — changes are metadata-only (submodule pointer updates) and do not modify control flow.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Possibly related PRs

• update subm #189 — Updates the same eloq submodule pointers (store_handler and tx_service); closely related submodule pointer changes.
• Fix slow open rocksdb cloud when DB is large #200 — Earlier update touching src/mongo/db/modules/eloq/store_handler pointer; this PR advances that pointer further.
• update submodules #198 — Prior change moving tx_service pointer to 48e5c862...; this PR advances it to 16f3cf1d....

Suggested reviewers

• liunyl

Poem

I nibble at a hash so new,
Hop—submodules shift their view.
No code was touched, no flow to mend,
Just pointers nudged from end to end.
A carrot cheer for CI too—🥕✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The title "Adjust hash partition mapping in Eloq submodules" is concise and directly reflects the PR's primary change of updating hash-partition handling in Eloq (store_handler and related tx_service sync); the PR objectives explicitly mention switching to the lower 10 hash bits and small cleanups which aligns with the title, and the file summaries show submodule bumps consistent with those adjustments. This phrasing is specific enough for a reviewer scanning history while remaining short and focused.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.

✨ Finishing touches

🧪 Generate unit tests

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between dc0bb89 and be12993.

📒 Files selected for processing (2)

• src/mongo/db/modules/eloq/store_handler (1 hunks)
• src/mongo/db/modules/eloq/tx_service (1 hunks)

✅ Files skipped from review due to trivial changes (1)

• src/mongo/db/modules/eloq/tx_service

🚧 Files skipped from review as they are similar to previous changes (1)

• src/mongo/db/modules/eloq/store_handler

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

src/mongo/db/modules/eloq/tx_service (1)

1-1: Submodule bump only—confirm compatibility with new 10‑bit hash partition mapping.

Looks fine as a pointer update. Please verify the paired eloq/store_handler bump (lower 10 hash bits) doesn’t conflict with any assumptions in this tx_service rev:

• No hard‑coded partition count/bit layout (e.g., masks > 0x3FF, ranges not equal to 1024).
• No persisted/on‑disk or cross‑service protocol fields storing prior partition IDs; if so, gate mapping by version or provide migration/backfill.
• Rollout: ensure mixed‑version clusters don’t route inconsistently during deploy; add a brief upgrade note if needed.
• Toolchain: std::ranges usage in store_handler implies C++20; confirm CI toolchain/stdlib is compatible here as well.

If all checks pass, I’m good with this.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 099e7df and dc0bb89.

📒 Files selected for processing (2)

• src/mongo/db/modules/eloq/store_handler (1 hunks)
• src/mongo/db/modules/eloq/tx_service (1 hunks)

🔇 Additional comments (1)

src/mongo/db/modules/eloq/store_handler (1)

1-1: Submodule bump to 6f5a167 — verify partition-remap risk & CI

• Status: store_handler submodule updated to 6f5a1678f7bcb9dc561372e7a733518f6e6671eb.
• Findings (quick scan):
  • Explicit 1024 usage / loop over partitions: src/mongo/db/modules/eloq/store_handler/dynamo_scanner.cpp (scan_res_.reserve(1024) ln327; future_vec.reserve(1024) ln338; for (partition < 1024) ln340).
  • HASH_PARTITION_COUNT used: src/mongo/db/modules/eloq/store_handler/data_store_service_scanner.cpp (partition_scanners_.reserve(HASH_PARTITION_COUNT); loop < HASH_PARTITION_COUNT) ln410–412.
  • std::ranges usage present: src/mongo/db/modules/eloq/store_handler/eloq_data_store_service/eloq_store_data_store.cpp (std::ranges::is_sorted ln199; std::ranges::sort ln208).
  • Key/row construction (possible persistent formats) to inspect for encoded partition bits: data_store_service_client.cpp (key/kv_range_record/segment_record ln1122,1158,1256), rocksdb_data_store_common.cpp (tmp_key append ln1085/1111), bigtable_handler.cpp (row_key/row_key_prefix ln1757,1979).
  • Scan did not produce definitive evidence that persistent keys encode the previous partition mapping; masking/shifting assumptions (e.g., &0x3ff, >>10/20) were not conclusively found in this pass.
• Action items:
  • Manually confirm no persistent key/metadata encodes the old partition mapping; if it does, gate the change and prepare a migration/backfill plan.
  • Add CI/unit test to assert uniformity of the hash low-10-bits (sample outputs) and fail on bias.
  • Ensure std::ranges usage compiles on all CI toolchains (add compile/test job if missing).
  • Grep for masking/shifting assumptions (e.g., &0x3ff, >>10, >>20) across repo and update callers or gate rollout.