Skip to content

Add func to convert ng configs to dss_config#249

Merged
lzxddz merged 1 commit intoeloqdata:update_cluster_configfrom
lzxddz:update_cluster_config
Oct 29, 2025
Merged

Add func to convert ng configs to dss_config#249
lzxddz merged 1 commit intoeloqdata:update_cluster_configfrom
lzxddz:update_cluster_config

Conversation

@lzxddz
Copy link
Collaborator

@lzxddz lzxddz commented Oct 29, 2025

eloqdata/store_handler#122
eloqdata/tx_service#181

Summary by CodeRabbit

  • Refactor
    • Optimized data store service configuration initialization to use in-memory configuration instead of file-based approach, improving startup efficiency.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Oct 29, 2025

Walkthrough

DSS config initialization in RedisServiceImpl transitions from file-based loading (dss_config.ini) to in-memory construction, introducing dss_leader_id logic and invoking TxConfigsToDssClusterConfig to populate cluster configuration.

Changes

Cohort / File(s) Change Summary
DSS Config Initialization
src/redis_service.cpp
Replaced file-based dss_config.ini loading path with in-memory ds_config object construction; introduces dss_leader_id assignment logic based on bootstrap flag; invokes EloqDS::DataStoreServiceClient::TxConfigsToDssClusterConfig to populate cluster config; previous file-based config loading/saving block is commented out

Sequence Diagram

sequenceDiagram
    autonumber
    participant Init as RedisServiceImpl::Init
    participant Config as In-Memory Config
    participant DSS as EloqDS::DataStoreServiceClient
    
    rect rgb(200, 220, 255)
    Note over Init,DSS: New Flow (In-Memory)
    Init->>Config: Create ds_config object
    Init->>Init: Determine dss_leader_id<br/>(bootstrap or single node)
    Init->>DSS: TxConfigsToDssClusterConfig<br/>(node_id, native_ng_id,<br/>ng_configs, dss_leader_id)
    DSS->>Config: Populate cluster config
    Config-->>Init: Config ready
    end
    
    rect rgb(240, 240, 240)
    Note over Init: Previous Path (Commented Out)
    Init--xInit: File-based dss_config.ini<br/>(no longer used)
    end
Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

  • Verify the in-memory ds_config object initialization is correctly structured and populated
  • Confirm dss_leader_id logic correctly handles bootstrap and single-node scenarios
  • Validate TxConfigsToDssClusterConfig call parameters match expected API signatures
  • Ensure removal of file-based config doesn't impact fallback or legacy code paths

Suggested labels

trigger-ci

Poem

🐰 A config once lived in a file on disk,
Now born in memory, nimble and brisk!
No file-seeking required, the path is so clean,
In-memory construction reigns supreme—
Bootstrap and leader, all in the scene!

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check ✅ Passed The title "Add func to convert ng configs to dss_config" is partially related to the changeset. The PR does involve using a conversion function (TxConfigsToDssClusterConfig) that converts node group configs to DSS cluster configuration, which aligns with the title's core concept. However, the title doesn't capture the main architectural change: a refactoring of the DSS config initialization path from file-based (dss_config.ini) to in-memory construction. The title focuses on one aspect of the implementation rather than the primary objective of the change.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • 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 ab95890 and 167b4ac.

📒 Files selected for processing (1)
  • src/redis_service.cpp (2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
  • src/redis_service.cpp

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

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

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
src/redis_service.cpp (1)

1027-1081: Remove commented-out code rather than leaving it in the codebase.

This large block of commented-out code (55 lines) should be removed entirely. The old implementation is preserved in version control history and can be referenced if needed. Keeping extensive commented code:

  • Clutters the codebase and reduces readability
  • Creates confusion about which code path is active
  • Makes maintenance harder

Apply this approach:

-        // std::string dss_config_file_path =
-        //     eloq_dss_data_path + "/dss_config.ini";
-        /*
-        EloqDS::DataStoreServiceClusterManager ds_config;
-        if (std::filesystem::exists(dss_config_file_path))
-        {
-            bool load_res = ds_config.Load(dss_config_file_path);
-            ...
-        }
-        ...
-        */
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 72096c7 and ab95890.

📒 Files selected for processing (3)
  • src/redis_service.cpp (2 hunks)
  • store_handler (1 hunks)
  • tx_service (1 hunks)
🔇 Additional comments (4)
store_handler (1)

1-1: Verify the intent and compatibility of the store_handler submodule update.

The submodule pointer has been updated, but the actual changes within the store_handler submodule are not visible in this review. Given that the broader PR refactors DSS config handling from file-based (dss_config.ini) to programmatic construction via TxConfigsToDssClusterConfig(), please confirm:

  1. That the store_handler update is intentional and necessary for this refactoring
  2. That the new commit is compatible with the in-memory cluster config construction approach
  3. That there are no breaking changes or API incompatibilities introduced
src/redis_service.cpp (3)

1017-1017: Verify that empty dss_config_file_path is acceptable to DataStoreService.

The dss_config_file_path is set to an empty string at line 1017 but is passed to the DataStoreService constructor at line 1108. The old commented-out code (lines 1027-1080) shows the previous implementation performed file operations (load/save) with this parameter. Verify against the external eloq_data_store_service library documentation or headers that the constructor correctly handles an empty path as a signal that no file-based configuration should be used.


1019-1023: Verify UINT32_MAX sentinel handling in external DataStoreService library.

The code appears to intentionally pass UINT32_MAX as dss_leader_id for multi-node, non-bootstrap deployments (lines 1019-1025). This sentinel value pattern is consistent with the codebase design. However, TxConfigsToDssClusterConfig() is part of the external EloqDS library and its implementation is not available in this repository. You must verify:

  1. The external library correctly handles UINT32_MAX as a valid sentinel value
  2. If leader election occurs within the DSS service after initialization with this value
  3. Whether multi-node production deployments require an alternative initialization strategy

1024-1025: Verify error handling for TxConfigsToDssClusterConfig and add checks if needed.

The return value at lines 1024-1025 is not captured, and there is no error checking before ds_config is used in the DataStoreService constructor at line 1107. This represents a regression from the old code (lines 1029-1081), which had five error paths: checking Load(), FetchConfigFromPeer(), Initialize(), and Save() results, each returning false on failure.

Since TxConfigsToDssClusterConfig is from the external EloqDS library, verify:

  1. Does the function have a return value or throw exceptions on failure?
  2. What are the failure modes for configuration population?
  3. Should error checking be added at the call site?

If the function can fail, add appropriate error checking and logging before using ds_config.

@lzxddz lzxddz force-pushed the update_cluster_config branch from ab95890 to 167b4ac Compare October 29, 2025 10:51
@lzxddz lzxddz changed the base branch from main to update_cluster_config October 29, 2025 10:55
@lzxddz lzxddz merged commit a7642ef into eloqdata:update_cluster_config Oct 29, 2025
4 checks passed
@coderabbitai coderabbitai bot mentioned this pull request Nov 3, 2025
githubzilla pushed a commit that referenced this pull request Nov 3, 2025
githubzilla pushed a commit that referenced this pull request Nov 4, 2025
@coderabbitai coderabbitai bot mentioned this pull request Nov 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant