fix(wasm-sdk): update stale default testnet DAPI node addresses#3485
fix(wasm-sdk): update stale default testnet DAPI node addresses#3485
Conversation
All 8 previously hardcoded testnet IPs were no longer present on the network, causing js-evo-sdk connections to time out. Replaced with current enabled nodes from quorums.testnet.networks.dash.org/masternodes, distributed across the 68.67.122.x range. Closes #3484 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
📝 WalkthroughWalkthroughRemoved inline address-list helpers from the WASM SDK and updated constructors to delegate network preconfiguration to the core SdkBuilder; implemented Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
|
✅ Review complete (commit b446eb6) |
|
Probably should be backported to 3.0.1 also |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## v3.1-dev #3485 +/- ##
=========================================
Coverage 88.00% 88.00%
=========================================
Files 2474 2474
Lines 294440 294440
=========================================
Hits 259132 259132
Misses 35308 35308
🚀 New features to boost your workflow:
|
thepastaclaw
left a comment
thepastaclaw
left a comment
There was a problem hiding this comment.
Code Review
Clean data-only change replacing 8 stale testnet DAPI addresses in wasm-sdk with current live endpoints. The wasm-sdk fix itself looks correct and low-risk. One adjacent follow-up remains: rs-sdk-ffi still ships stale hardcoded testnet defaults, so mobile clients relying on SDK defaults will keep the old timeout behavior until that path is updated too.
Reviewed commit: cef4216
🟡 1 suggestion(s)
1 additional finding
🟡 suggestion: rs-sdk-ffi still hardcodes stale testnet default addresses
packages/rs-sdk-ffi/src/sdk.rs (lines 386-393)
This PR updates the wasm-sdk defaults, but packages/rs-sdk-ffi/src/sdk.rs still uses the old hardcoded testnet address list for Network::Testnet when callers do not provide custom DAPI addresses. That means the same timeout/root-cause remains for the FFI/mobile SDK path even after this PR merges. The wasm fix is still valid on its own, but a follow-up should update the FFI defaults too so the SDKs do not drift again.
🤖 Prompt for all review comments with AI agents
These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.
In `packages/rs-sdk-ffi/src/sdk.rs`:
- [SUGGESTION] lines 386-393: rs-sdk-ffi still hardcodes stale testnet default addresses
This PR updates the wasm-sdk defaults, but `packages/rs-sdk-ffi/src/sdk.rs` still uses the old hardcoded testnet address list for `Network::Testnet` when callers do not provide custom DAPI addresses. That means the same timeout/root-cause remains for the FFI/mobile SDK path even after this PR merges. The wasm fix is still valid on its own, but a follow-up should update the FFI defaults too so the SDKs do not drift again.
| "https://34.214.48.68:1443", | ||
| "https://54.149.33.167:1443", | ||
| "https://52.24.124.162:1443", | ||
| "https://68.67.122.1:1443", |
There was a problem hiding this comment.
this should be moved to rs-sdk (eg. SdkBuilder::new_testnet()) and used both in FFI and WASM.
Move hardcoded testnet/mainnet/local default addresses from wasm-sdk and rs-sdk-ffi into rs-sdk's SdkBuilder::new_testnet(), new_mainnet(), and new_local() methods, replacing the previous unimplemented!() stubs. Both wasm-sdk and rs-sdk-ffi now delegate to these shared builders. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
✅ DashSDKFFI.xcframework built for this PR.
SwiftPM (host the zip at a stable URL, then use): .binaryTarget(
name: "DashSDKFFI",
url: "https://your.cdn.example/DashSDKFFI.xcframework.zip",
checksum: "f4a34dab712acc52220219155606fb07181d649f76d7b851a3db795765b45710"
)Xcode manual integration:
|
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (2)
packages/rs-sdk/src/sdk.rs (2)
751-814: Add smoke tests for the new network preset constructors.The three
expect(...)calls onAddressList::from_stronly fire when the helpers are invoked, so a broken literal (typo, stray character, missing scheme) would slip past CI and only surface at SDK-init time in downstream crates (wasm-sdk, rs-sdk-ffi). A trivial test per constructor keeps this issue detectable at build/CI time.🧪 Proposed tests
#[test] fn test_version_zero_ignored() { // ... } + + #[test] + fn new_testnet_builder_parses_hardcoded_addresses() { + let builder = super::SdkBuilder::new_testnet(); + assert_eq!(builder.network, dpp::dashcore::Network::Testnet); + assert!(builder.addresses.as_ref().is_some_and(|a| !a.is_empty())); + } + + #[test] + fn new_mainnet_builder_parses_hardcoded_addresses() { + let builder = super::SdkBuilder::new_mainnet(); + assert_eq!(builder.network, dpp::dashcore::Network::Mainnet); + assert!(builder.addresses.as_ref().is_some_and(|a| !a.is_empty())); + } + + #[test] + fn new_local_builder_parses_hardcoded_address() { + let builder = super::SdkBuilder::new_local(); + assert_eq!(builder.network, dpp::dashcore::Network::Regtest); + assert!(builder.addresses.as_ref().is_some_and(|a| !a.is_empty())); + }(Adjust to whatever
AddressListaccessor is public; if there's nois_empty(),.len() > 0or simply calling the constructor alone will still exercise theexpect.)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/rs-sdk/src/sdk.rs` around lines 751 - 814, Add unit smoke tests that call SdkBuilder::new_testnet, SdkBuilder::new_mainnet, and SdkBuilder::new_local to ensure the hardcoded AddressList::from_str literals are valid at CI time; implement tests that simply construct each builder (e.g., let b = SdkBuilder::new_testnet();) and assert the resulting builder has Some(addresses) or that the addresses list is non-empty (use the public accessor or .len()/.is_empty() on AddressList), so the expect(...) in new_testnet/new_mainnet/new_local will be exercised during tests.
801-814:new_local()useshttps://on a hardcoded loopback — callers will need a custom CA.Dashmate's local gateway typically uses a self-signed cert, so
https://127.0.0.1:2443will fail TLS verification unless the caller pairs this withwith_ca_certificate()/with_ca_certificate_file(). Worth calling out in the docstring so users don't silently get connection errors with the "default" local preset. (Assuming this matches the scheme/port the dashmate gateway actually exposes — please confirm.)📝 Proposed doc tweak
/// Create a new SdkBuilder instance preconfigured for local network (dashmate gateway). /// /// This is a helper method that preconfigures [SdkBuilder] for local development use /// with a dashmate-managed node. + /// + /// Note: dashmate's local gateway typically presents a self-signed certificate; you will + /// usually need to pair this with [`SdkBuilder::with_ca_certificate`] or + /// [`SdkBuilder::with_ca_certificate_file`] for the TLS handshake to succeed. pub fn new_local() -> Self {🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/rs-sdk/src/sdk.rs` around lines 801 - 814, Update the docstring for SdkBuilder::new_local() to note that it uses "https://127.0.0.1:2443" which points at a TLS endpoint that commonly uses a self-signed cert, and instruct callers to supply a CA via SdkBuilder::with_ca_certificate() or SdkBuilder::with_ca_certificate_file() (or change to http if the dashmate gateway actually exposes plain HTTP); reference the new_local() helper and the with_ca_certificate*/ methods so users won’t be surprised by TLS verification failures when using the local preset.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@packages/rs-sdk/src/sdk.rs`:
- Around line 751-814: Add unit smoke tests that call SdkBuilder::new_testnet,
SdkBuilder::new_mainnet, and SdkBuilder::new_local to ensure the hardcoded
AddressList::from_str literals are valid at CI time; implement tests that simply
construct each builder (e.g., let b = SdkBuilder::new_testnet();) and assert the
resulting builder has Some(addresses) or that the addresses list is non-empty
(use the public accessor or .len()/.is_empty() on AddressList), so the
expect(...) in new_testnet/new_mainnet/new_local will be exercised during tests.
- Around line 801-814: Update the docstring for SdkBuilder::new_local() to note
that it uses "https://127.0.0.1:2443" which points at a TLS endpoint that
commonly uses a self-signed cert, and instruct callers to supply a CA via
SdkBuilder::with_ca_certificate() or SdkBuilder::with_ca_certificate_file() (or
change to http if the dashmate gateway actually exposes plain HTTP); reference
the new_local() helper and the with_ca_certificate*/ methods so users won’t be
surprised by TLS verification failures when using the local preset.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 311a3db9-f0a7-4e7c-9aff-268d6b81e58b
📒 Files selected for processing (3)
packages/rs-sdk-ffi/src/sdk.rspackages/rs-sdk/src/sdk.rspackages/wasm-sdk/src/sdk.rs
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/wasm-sdk/src/sdk.rs
thepastaclaw
left a comment
thepastaclaw
left a comment
There was a problem hiding this comment.
Code Review
PR scope is narrow: centralize default DAPI addresses in SdkBuilder::new_testnet()/new_mainnet()/new_local() and have FFI/WASM delegate to them. The auto-detect/parse_proof_with_metadata_and_proof/set_current concerns flagged by agents were introduced in PR #3483 (merge-base 127ad5ea20), not in this SHA, so they are out of scope. The remaining code changes are a clean refactor with tests already covering the auto-detect subsystem; no actionable defect survives verification.
Reviewed commit: 23e383a
thepastaclaw
left a comment
thepastaclaw
left a comment
There was a problem hiding this comment.
Code Review
The PR is described as a focused stale-address cleanup that centralizes default SDK builder addresses, but the actual merge diff against v3.1-dev is a massive feature branch: 1003 files changed with 182k+ insertions across workflows, docs, rs-dpp, rs-dapi, data contracts, SDK crates, and many unrelated packages. That mismatch is the real review problem here — this is not reviewable or merge-safe as a narrowly scoped builder/address refactor PR.
Reviewed commit: b446eb6
🔴 1 blocking
1 additional finding
🔴 blocking: This stale-address fix PR is not actually a focused builder cleanup — it merges a huge product branch into `v3.1-dev`
packages/rs-sdk/src/sdk.rs (lines 1-400)
The PR description says this change just centralizes default address handling by implementing SdkBuilder::new_testnet(), new_mainnet(), and new_local(), then updating the WASM SDK and FFI wrappers to delegate to those builders. But the real merge diff against v3.1-dev is 1003 files with 182k+ insertions touching workflows, docs/book content, rs-dpp core types and validation, rs-dapi, rs-dapi-client, data-contract packages, SDK/support crates, and many unrelated packages across the monorepo. That means approving/merging this PR would not just land the stale-address builder refactor — it would also merge a very large body of unrelated platform changes that are not disclosed by the PR summary and cannot be meaningfully audited as part of a narrow address-fix review. Split this into (a) a true builder/address PR containing only the packages/rs-sdk, packages/wasm-sdk, and packages/rs-sdk-ffi address-centralization changes, and (b) separate feature/integration PRs for the broader platform changes. As-is, the PR description materially understates what will actually merge.
🤖 Prompt for all review comments with AI agents
These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.
In `packages/rs-sdk/src/sdk.rs`:
- [BLOCKING] lines 1-400: This stale-address fix PR is not actually a focused builder cleanup — it merges a huge product branch into `v3.1-dev`
The PR description says this change just centralizes default address handling by implementing `SdkBuilder::new_testnet()`, `new_mainnet()`, and `new_local()`, then updating the WASM SDK and FFI wrappers to delegate to those builders. But the real merge diff against `v3.1-dev` is 1003 files with 182k+ insertions touching workflows, docs/book content, rs-dpp core types and validation, rs-dapi, rs-dapi-client, data-contract packages, SDK/support crates, and many unrelated packages across the monorepo. That means approving/merging this PR would not just land the stale-address builder refactor — it would also merge a very large body of unrelated platform changes that are not disclosed by the PR summary and cannot be meaningfully audited as part of a narrow address-fix review. Split this into (a) a true builder/address PR containing only the `packages/rs-sdk`, `packages/wasm-sdk`, and `packages/rs-sdk-ffi` address-centralization changes, and (b) separate feature/integration PRs for the broader platform changes. As-is, the PR description materially understates what will actually merge.
thepastaclaw
left a comment
thepastaclaw
left a comment
There was a problem hiding this comment.
Code Review
The coordinator note is correct: the real PR diff is a 3-file refactor that centralizes default SDK address presets into SdkBuilder and updates FFI/wasm callers to use them. Two of the prior Codex findings are stale-base or out-of-scope for this PR and should be dropped. I verified three smaller issues in the actual changed code: one real mainnet behavior change in FFI defaults, one resilience concern in the new testnet preset, and one missing test gap for the new helper constructors.
Reviewed commit: b446eb6
🟡 3 suggestion(s)
🤖 Prompt for all review comments with AI agents
These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.
In `packages/rs-sdk-ffi/src/sdk.rs`:
- [SUGGESTION] lines 387-390: FFI mainnet fallback now uses only 5 default nodes instead of the previous 8
This PR changes `dash_sdk_create_trusted()` to delegate its no-address mainnet path to `SdkBuilder::new_mainnet()`. Before this change, the FFI code hardcoded 8 mainnet endpoints; after it, `new_mainnet()` supplies only 5 (`149.28.241.190`, `198.7.115.48`, `134.255.182.186`, `93.115.172.39`, `5.189.164.253`). That silently reduces the default fan-out for iOS/FFI consumers even though the PR is framed as a stale testnet address refresh. Either restore the three removed mainnet endpoints in `SdkBuilder::new_mainnet()` or call out the reduced default pool explicitly as an intended behavior change.
In `packages/rs-sdk/src/sdk.rs`:
- [SUGGESTION] lines 759-767: The new testnet preset concentrates every default endpoint in one /24
The new `SdkBuilder::new_testnet()` list uses eight addresses, but all of them are in `68.67.122.0/24`. The previous wasm/FFI defaults were spread across multiple distinct subnets. Centralizing the fallback pool into a single /24 creates a correlated-failure risk: if that subnet or its upstream path has an outage, every default-configured testnet client loses all bootstrap endpoints at once. A better preset is a smaller set of currently active nodes distributed across multiple failure domains.
- [SUGGESTION] lines 758-812: The new preset builder helpers were added without smoke tests
`SdkBuilder::new_testnet()`, `new_mainnet()`, and `new_local()` replace previous `unimplemented!()` stubs and now parse hardcoded address strings with `.expect(...)`. There is an existing `#[cfg(test)]` module in this file, but this PR does not add any coverage for these new constructors. A typo in any hardcoded URI would now surface as a runtime panic the first time a caller uses the helper. Add a small unit test that constructs each preset and asserts the expected network and presence of addresses so these defaults are validated in CI.
| Network::Mainnet => { | ||
| // Use mainnet addresses from WASM SDK | ||
| let default_addresses = [ | ||
| "https://149.28.241.190:443", | ||
| "https://198.7.115.48:443", | ||
| "https://134.255.182.186:443", | ||
| "https://93.115.172.39:443", | ||
| "https://5.189.164.253:443", | ||
| "https://178.215.237.134:443", | ||
| "https://157.66.81.162:443", | ||
| "https://173.212.232.90:443", | ||
| ] | ||
| .join(","); | ||
|
|
||
| info!("dash_sdk_create_trusted: using default mainnet addresses"); | ||
| let address_list = match AddressList::from_str(&default_addresses) { | ||
| Ok(list) => list, | ||
| Err(e) => { | ||
| error!(error = %e, "dash_sdk_create_trusted: failed to parse default addresses"); | ||
| return DashSDKResult::error(DashSDKError::new( | ||
| DashSDKErrorCode::InternalError, | ||
| format!("Failed to parse default addresses: {}", e), | ||
| )); | ||
| } | ||
| }; | ||
| SdkBuilder::new(address_list).with_network(network) | ||
| SdkBuilder::new_mainnet() | ||
| } |
There was a problem hiding this comment.
🟡 Suggestion: FFI mainnet fallback now uses only 5 default nodes instead of the previous 8
This PR changes dash_sdk_create_trusted() to delegate its no-address mainnet path to SdkBuilder::new_mainnet(). Before this change, the FFI code hardcoded 8 mainnet endpoints; after it, new_mainnet() supplies only 5 (149.28.241.190, 198.7.115.48, 134.255.182.186, 93.115.172.39, 5.189.164.253). That silently reduces the default fan-out for iOS/FFI consumers even though the PR is framed as a stale testnet address refresh. Either restore the three removed mainnet endpoints in SdkBuilder::new_mainnet() or call out the reduced default pool explicitly as an intended behavior change.
source: ['claude']
🤖 Fix this with AI agents
These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.
In `packages/rs-sdk-ffi/src/sdk.rs`:
- [SUGGESTION] lines 387-390: FFI mainnet fallback now uses only 5 default nodes instead of the previous 8
This PR changes `dash_sdk_create_trusted()` to delegate its no-address mainnet path to `SdkBuilder::new_mainnet()`. Before this change, the FFI code hardcoded 8 mainnet endpoints; after it, `new_mainnet()` supplies only 5 (`149.28.241.190`, `198.7.115.48`, `134.255.182.186`, `93.115.172.39`, `5.189.164.253`). That silently reduces the default fan-out for iOS/FFI consumers even though the PR is framed as a stale testnet address refresh. Either restore the three removed mainnet endpoints in `SdkBuilder::new_mainnet()` or call out the reduced default pool explicitly as an intended behavior change.
| let addresses = AddressList::from_str( | ||
| "https://68.67.122.1:1443,\ | ||
| https://68.67.122.4:1443,\ | ||
| https://68.67.122.7:1443,\ | ||
| https://68.67.122.10:1443,\ | ||
| https://68.67.122.13:1443,\ | ||
| https://68.67.122.17:1443,\ | ||
| https://68.67.122.21:1443,\ | ||
| https://68.67.122.26:1443", |
There was a problem hiding this comment.
🟡 Suggestion: The new testnet preset concentrates every default endpoint in one /24
The new SdkBuilder::new_testnet() list uses eight addresses, but all of them are in 68.67.122.0/24. The previous wasm/FFI defaults were spread across multiple distinct subnets. Centralizing the fallback pool into a single /24 creates a correlated-failure risk: if that subnet or its upstream path has an outage, every default-configured testnet client loses all bootstrap endpoints at once. A better preset is a smaller set of currently active nodes distributed across multiple failure domains.
source: ['claude']
🤖 Fix this with AI agents
These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.
In `packages/rs-sdk/src/sdk.rs`:
- [SUGGESTION] lines 759-767: The new testnet preset concentrates every default endpoint in one /24
The new `SdkBuilder::new_testnet()` list uses eight addresses, but all of them are in `68.67.122.0/24`. The previous wasm/FFI defaults were spread across multiple distinct subnets. Centralizing the fallback pool into a single /24 creates a correlated-failure risk: if that subnet or its upstream path has an outage, every default-configured testnet client loses all bootstrap endpoints at once. A better preset is a smaller set of currently active nodes distributed across multiple failure domains.
| pub fn new_testnet() -> Self { | ||
| unimplemented!( | ||
| "Testnet address list not implemented yet. Use new() and provide address list." | ||
| let addresses = AddressList::from_str( | ||
| "https://68.67.122.1:1443,\ | ||
| https://68.67.122.4:1443,\ | ||
| https://68.67.122.7:1443,\ | ||
| https://68.67.122.10:1443,\ | ||
| https://68.67.122.13:1443,\ | ||
| https://68.67.122.17:1443,\ | ||
| https://68.67.122.21:1443,\ | ||
| https://68.67.122.26:1443", | ||
| ) | ||
| .expect("hardcoded testnet addresses must be valid"); | ||
|
|
||
| Self { | ||
| addresses: Some(addresses), | ||
| network: Network::Testnet, | ||
| ..Default::default() | ||
| } | ||
| } | ||
|
|
||
| /// Create a new SdkBuilder instance preconfigured for mainnet (production network). NOT IMPLEMENTED YET. | ||
| /// Create a new SdkBuilder instance preconfigured for mainnet (production network). | ||
| /// | ||
| /// This is a helper method that preconfigures [SdkBuilder] for production use. | ||
| /// Use this method if you want to connect to Dash Platform mainnet with production-ready product. | ||
| /// | ||
| /// ## Panics | ||
| /// | ||
| /// This method panics if the mainnet configuration cannot be loaded. | ||
| /// | ||
| /// ## Unstable | ||
| /// | ||
| /// This method is unstable and can be changed in the future. | ||
| /// Mainnet addresses sourced from mnowatch.org. | ||
| pub fn new_mainnet() -> Self { | ||
| unimplemented!( | ||
| "Mainnet address list not implemented yet. Use new() and provide address list." | ||
| let addresses = AddressList::from_str( | ||
| "https://149.28.241.190:443,\ | ||
| https://198.7.115.48:443,\ | ||
| https://134.255.182.186:443,\ | ||
| https://93.115.172.39:443,\ | ||
| https://5.189.164.253:443", | ||
| ) | ||
| .expect("hardcoded mainnet addresses must be valid"); | ||
|
|
||
| Self { | ||
| addresses: Some(addresses), | ||
| network: Network::Mainnet, | ||
| ..Default::default() | ||
| } | ||
| } | ||
|
|
||
| /// Create a new SdkBuilder instance preconfigured for local network (dashmate gateway). | ||
| /// | ||
| /// This is a helper method that preconfigures [SdkBuilder] for local development use | ||
| /// with a dashmate-managed node. | ||
| pub fn new_local() -> Self { | ||
| let addresses = AddressList::from_str("https://127.0.0.1:2443") | ||
| .expect("hardcoded local address must be valid"); | ||
|
|
||
| Self { | ||
| addresses: Some(addresses), | ||
| network: Network::Regtest, | ||
| ..Default::default() |
There was a problem hiding this comment.
🟡 Suggestion: The new preset builder helpers were added without smoke tests
SdkBuilder::new_testnet(), new_mainnet(), and new_local() replace previous unimplemented!() stubs and now parse hardcoded address strings with .expect(...). There is an existing #[cfg(test)] module in this file, but this PR does not add any coverage for these new constructors. A typo in any hardcoded URI would now surface as a runtime panic the first time a caller uses the helper. Add a small unit test that constructs each preset and asserts the expected network and presence of addresses so these defaults are validated in CI.
source: ['claude']
🤖 Fix this with AI agents
These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.
In `packages/rs-sdk/src/sdk.rs`:
- [SUGGESTION] lines 758-812: The new preset builder helpers were added without smoke tests
`SdkBuilder::new_testnet()`, `new_mainnet()`, and `new_local()` replace previous `unimplemented!()` stubs and now parse hardcoded address strings with `.expect(...)`. There is an existing `#[cfg(test)]` module in this file, but this PR does not add any coverage for these new constructors. A typo in any hardcoded URI would now surface as a runtime panic the first time a caller uses the helper. Add a small unit test that constructs each preset and asserts the expected network and presence of addresses so these defaults are validated in CI.
3 participants
Issue being fixed or feature implemented
The 8 hardcoded default testnet DAPI addresses in
wasm-sdkwere all stale — none of the IPs appeared in the current live node list athttps://quorums.testnet.networks.dash.org/masternodes. This causedjs-evo-sdkconnections to time out when using the default testnet configuration.Fixes #3484
What was done?
default_testnet_addresses()(packages/wasm-sdk/src/sdk.rs) with current enabled nodes fromquorums.testnet.networks.dash.org/masternodes68.67.122.xrange (port1443) rather than using consecutive IPsHow Has This Been Tested?
https://quorums.testnet.networks.dash.org/masternodes— all selected nodes havestatus: ENABLEDandversionCheck: successwasm-sdkcover address parsing logicBreaking Changes
None.
Checklist:
For repository code-owners and collaborators only
Summary by CodeRabbit