test(sdk): generate test vectors using testnet

[lklimek]

Issue being fixed or feature implemented

We want to easily generate test vectors for Rust SDK using testnet. Unfortunately, it requires access to Dash Core RPC which only listens on 127.0.0.1 on the server.

What was done?

1. Added setting DASH_SDK_CORE_HOST to rs-sdk tests configuration, defaults to DASH_SDK_PLATFORM_HOST for backwards compatibility.
2. Added script to generate .env file for rs-sdk test generation and establish SSH tunnel for Dash Core.

How Has This Been Tested?

Regenerate test vectors against testnet.

Breaking Changes

None

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have added "!" to the title and described breaking changes in the corresponding section if my code contains any
• I have made corresponding changes to the documentation if needed

For repository code-owners and collaborators only

• I have assigned this pull request to a milestone

Summary by CodeRabbit

• New Features

  • Introduced a new script to facilitate connection to a remote node for executing SDK tests.
  • Added a new configuration variable for specifying the Dash Core host in testing.

• Documentation

  • Updated the README to clarify instructions for offline testing and generating test vectors.
  • Enhanced comments in scripts to guide users on using the new connection script.

• Tests

  • Added a test suite for verifying the status of EvoNodes, covering both successful and erroneous scenarios.

[coderabbitai]

Walkthrough

The pull request introduces enhancements to the Dash Platform Rust SDK documentation and scripts. Key changes include updates to the README.md for improved clarity on offline testing and test vector generation, the addition of a new script connect_to_remote.sh for connecting to remote nodes, and modifications to existing scripts to reference this new functionality. Additionally, configuration files have been updated to include new variables, enhancing the flexibility of the SDK's testing environment.

Changes

File Path	Change Summary
packages/rs-sdk/README.md	Updated instructions for offline testing and generating test vectors; clarified .env file usage.
packages/rs-sdk/scripts/connect_to_remote.sh	New script added to facilitate connection to a remote node for executing SDK tests, including SSH handling.
packages/rs-sdk/scripts/generate_test_vectors.sh	Added a comment suggesting the use of connect_to_remote.sh for remote node connections.
packages/rs-sdk/tests/.env.example	Added DASH_SDK_CORE_HOST variable for specifying Dash Core host for RPC.
packages/rs-sdk/tests/fetch/config.rs	Introduced core_host field to Config struct for specifying Dash Core RPC host; modified setup logic.
packages/rs-sdk/tests/fetch/evonode.rs	Added a test suite for EvoNode status retrieval, covering both successful and erroneous scenarios.

Possibly related PRs

• feat(sdk): get node status #2139: The main PR updates the README and introduces a new script for connecting to remote nodes, which is relevant to the changes in the FetchUnproved trait and the EvoNode struct in this PR, as both involve handling node statuses and connections.
• fix(sdk): small sdk improvements and fixes for v1.4 #2200: This PR includes improvements to the SDK that relate to node status retrieval, which aligns with the main PR's focus on enhancing documentation and scripts for testing against nodes.
• feat: start network with latest version if genesis version not set #2206: The modifications in this PR regarding network configurations could indirectly relate to the main PR's updates on connecting to nodes, as both deal with network settings.
• fix(platform): fixed Platform State deserialization issue #2227: The introduction of a new error type related to the Dash Core in this PR may connect with the main PR's focus on enhancing SDK functionality, particularly in error handling during node interactions.
• feat(sdk)!: detect stale nodes #2254: The detection of stale nodes in this PR connects with the main PR's focus on improving SDK functionality and error handling when interacting with nodes.
• fix: seed nodes aren't responding #2276: The addition of fallback seed nodes in this PR enhances the SDK's ability to connect to nodes, which is relevant to the main PR's updates on node connection scripts.
• refactor(sdk)!: separate dash core client error #2380: The introduction of the DashCoreError type in this PR enhances error handling in the SDK, which is relevant to the main PR's focus on improving usability and error management in node interactions.

Suggested labels

enhancement, js-sdk

Suggested reviewers

• QuantumExplorer
• shumkov

Poem

🐰 In the meadow where bunnies play,
New scripts and docs brighten the day.
With tunnels to nodes, oh what a delight,
Testing is easier, everything feels right!
So hop along, let’s code and cheer,
For the Dash SDK, the future is near! 🌟

---

📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 8a7a241 and 8737420.

📒 Files selected for processing (3)

• packages/rs-sdk/scripts/connect_to_remote.sh (1 hunks)
• packages/rs-sdk/tests/fetch/config.rs (3 hunks)
• packages/rs-sdk/tests/fetch/evonode.rs (0 hunks)

💤 Files with no reviewable changes (1)

• packages/rs-sdk/tests/fetch/evonode.rs

🧰 Additional context used

📓 Learnings (1)

packages/rs-sdk/scripts/connect_to_remote.sh (1)

Learnt from: lklimek
PR: dashpay/platform#2381
File: packages/rs-sdk/scripts/connect_to_remote.sh:44-48
Timestamp: 2024-12-10T12:29:22.522Z
Learning: The `connect_to_remote.sh` script is a helper tool intended for internal use, so extensive configuration validation is not necessary.

🔇 Additional comments (2)

packages/rs-sdk/scripts/connect_to_remote.sh (1)

1-91: The script is well-structured and functions correctly

The connect_to_remote.sh script is correctly implemented, with appropriate error handling and necessary configurations for internal use.

packages/rs-sdk/tests/fetch/config.rs (1)

39-43: New configuration field core_host is correctly added and utilized

The addition of the optional core_host field to the Config struct and its usage in the setup_api method are properly implemented, enhancing the configurability of the SDK.

Also applies to: 188-191

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR. (Experiment)
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

Actionable comments posted: 5

🧹 Outside diff range and nitpick comments (5)

packages/rs-sdk/README.md (1)

80-84: Consider adding more context about the helper script.

The documentation clearly explains the new remote connection functionality. Consider adding:

1. The full path to the helper script for easier discovery
2. A note mentioning this is particularly useful for testnet vector generation, aligning with the PR's main objective

-To generate test vectors against a testnet node (or other remote node), you can use helper script
-`packages/rs-sdk/scripts/connect_to_remote.sh` which will generate `.env` file for you and tunnel connection to Dash
-Core RPC on the remote host.
+To generate test vectors against a testnet node (or other remote node), you can use the helper script
+`packages/rs-sdk/scripts/connect_to_remote.sh`. This script is particularly useful for testnet vector generation as it will:
+- Generate the `.env` file with appropriate configuration
+- Establish a secure tunnel to access the remote Dash Core RPC

packages/rs-sdk/tests/fetch/config.rs (2)

39-43: LGTM! Consider enhancing documentation.

The new core_host field is well-structured and properly integrated. The implementation correctly handles optional values and feature flags.

Consider adding an example value in the documentation to make it clearer for users:

 /// Host of the Dash Core RPC interface running on the Dash Platform node.
 /// Defaults to the same as [platform_host](Config::platform_host).
+/// Example: "127.0.0.1" or "testnet.example.com"

---

188-191: Consider enhancing robustness and idiomaticity.

While the implementation is functionally correct, consider these improvements:

1. Use as_deref() for more idiomatic Option handling
2. Add basic validation for the host value

-            let core_host = self.core_host.as_ref().unwrap_or(&self.platform_host);
+            let core_host = self.core_host.as_deref().unwrap_or(&self.platform_host);
+            // Basic validation to ensure host is not empty and has valid format
+            if core_host.trim().is_empty() {
+                panic!("core_host cannot be empty");
+            }
             // Dump all traffic to disk
             let builder = dash_sdk::SdkBuilder::new(self.address_list()).with_core(

packages/rs-sdk/scripts/connect_to_remote.sh (2)

1-6: Add shellcheck directive and consider making CORE_USER configurable.

Good error handling setup, but a few improvements could make the script more robust:

 #! /bin/bash
+# shellcheck disable=SC2029
 
 set -e -o pipefail
 
-CORE_USER=dashmate
+CORE_USER="${DASH_CORE_USER:-dashmate}"

The shellcheck directive is needed because we're intentionally allowing command expansion on the remote side for SSH commands.

---

50-66: Add safety measures for .env file generation.

Consider adding backup functionality and configurable ports:

+LOCAL_PORT="${DASH_LOCAL_PORT:-12367}"
+
 ENV_FILE="$(realpath "$0" | xargs dirname)/../tests/.env"
+
+# Backup existing .env file
+if [ -f "${ENV_FILE}" ]; then
+    mv "${ENV_FILE}" "${ENV_FILE}.backup"
+    echo "Backed up existing .env file to ${ENV_FILE}.backup"
+fi
+
 echo -n Generating "{$ENV_FILE}" file for the SDK tests...

 cat >"${ENV_FILE}" <<EOF
 # Configuration of tests and examples, generated by $(realpath "$0")
 
 DASH_SDK_PLATFORM_HOST="${REMOTE_NODE}"
 DASH_SDK_PLATFORM_PORT=${DAPI_PORT}
 DASH_SDK_PLATFORM_SSL=${DAPI_SSL_ENABLED}
 
 
 DASH_SDK_CORE_HOST=127.0.0.1
-DASH_SDK_CORE_PORT=12367
+DASH_SDK_CORE_PORT=${LOCAL_PORT}
 DASH_SDK_CORE_USER="${CORE_USER}"
 DASH_SDK_CORE_PASSWORD="${CORE_PASSWORD}"
 EOF

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 6270ef0 and 8a7a241.

📒 Files selected for processing (5)

• packages/rs-sdk/README.md (1 hunks)
• packages/rs-sdk/scripts/connect_to_remote.sh (1 hunks)
• packages/rs-sdk/scripts/generate_test_vectors.sh (1 hunks)
• packages/rs-sdk/tests/.env.example (1 hunks)
• packages/rs-sdk/tests/fetch/config.rs (2 hunks)

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

• packages/rs-sdk/tests/.env.example
• packages/rs-sdk/scripts/generate_test_vectors.sh

🔇 Additional comments (3)

packages/rs-sdk/README.md (1)

77-79: LGTM! Clear and accurate documentation.

The explanation of the test vector generation script's functionality is well-written and provides the necessary information for users.

packages/rs-sdk/tests/fetch/config.rs (1)

188-194: Verify integration with test vector generation.

The implementation looks correct, but let's verify the integration with test vector generation functionality.

✅ Verification successful

Let me gather more information about the test vector generation implementation to ensure proper integration.

---

Integration with test vector generation is properly implemented

The implementation correctly integrates with test vector generation:

• Test vectors are generated in tests/vectors directory using the generate-test-vectors feature
• The core_host configuration is properly used in the SDK builder, defaulting to platform_host when not specified
• Test vector generation can be configured to use different core hosts (local/testnet) via environment variables

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify test vector generation configuration and integration

# Check if test vector generation is properly configured
echo "Checking test vector generation configuration..."

# Look for test vector generation related files
fd -t f "generate.*test.*vectors" -x echo "Found test vector file: {}"

# Check for environment variable usage in test files
echo "Checking for DASH_SDK_CORE_HOST usage..."
rg "DASH_SDK_CORE_HOST" -A 3

# Check for test vector output paths
echo "Checking test vector output paths..."
fd -t d "vectors" -x echo "Found vectors directory: {}"

Length of output: 880

---

Script:

#!/bin/bash
# Check the test vector generation script content
echo "Checking test vector generation script..."
cat ./packages/rs-sdk/scripts/generate_test_vectors.sh

# Check test vector related test files
echo -e "\nChecking test files using test vectors..."
rg -l "vectors" packages/rs-sdk/tests/

# Check if core_host is properly used in test vector generation
echo -e "\nChecking core_host usage in tests..."
rg "core_host" packages/rs-sdk/tests/ -A 2

Length of output: 2137

packages/rs-sdk/scripts/connect_to_remote.sh (1)

7-22: LGTM! Well-documented usage function.

The usage instructions are clear, comprehensive, and include helpful examples.

The base branch was changed.