Open
Conversation
Contributor
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughUpdated workspace dependency revisions and removed Changes
Sequence Diagram(s)sequenceDiagram
participant App as Swift App
participant SPV as SPVClient (Swift)
participant FFI as FFI layer (UnifiedSDK)
participant Core as dash_spv_ffi / Core SPV
App->>SPV: init(..., progressHandler?, syncHandler?, networkHandler?, walletHandler?)
SPV->>FFI: buildFFIEventCallbacks(...) / dash_spv_ffi_client_new(configPtr, callbacks)
FFI->>Core: create SPV client with callbacks
Core-->>FFI: invoke callbacks on events
FFI-->>SPV: converted callbacks invoked (via FFIEventCallbacks)
SPV-->>App: call stored Swift handlers (progress/sync/network/wallet)
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
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 (3)
packages/rs-drive-abci/tests/strategy_tests/masternodes.rs (2)
528-530:⚠️ Potential issue | 🟠 MajorSame issue as regular masternodes: HPMN IP update logic needs Option handling.
This code has the same potential type mismatch as the regular masternode IP update logic on lines 351-354.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/rs-drive-abci/tests/strategy_tests/masternodes.rs` around lines 528 - 530, The HPMN IP update assumes state.service is always present but it may be an Option; update the logic around hpmn_list_item_b.state.service so it handles the Option case (e.g., match or map the Option), preserving the existing port when Some(SocketAddr) and leaving None untouched (or creating Some(SocketAddr::new(IpAddr::V4(random_ip), old_port)) only when there is an existing address). Refer to identifiers hpmn_list_item_b, state.service, SocketAddr::new and IpAddr::V4(random_ip) when locating and fixing the code.
351-354:⚠️ Potential issue | 🔴 CriticalFix type mismatch:
DMNState.serviceisOption<SocketAddr>, but code accesses it as bareSocketAddr.Lines 351-354 call
.port()directly onstate.serviceand assign a bareSocketAddrwithout wrapping inSome(). SinceDMNState.serviceisOption<SocketAddr>, this code will not compile. Update to:Suggested fix
let old_port = masternode_list_item_b.state.service.as_ref().map(|s| s.port()).unwrap_or(1234); masternode_list_item_b.state.service = Some(SocketAddr::new(IpAddr::V4(random_ip), old_port));Same issue exists at line 528 for
hpmn_list_item_b.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/rs-drive-abci/tests/strategy_tests/masternodes.rs` around lines 351 - 354, DMNState.service is an Option<SocketAddr> but the code treats it as a bare SocketAddr; change the reads to safely extract the port (e.g., masternode_list_item_b.state.service.as_ref().map(|s| s.port()).unwrap_or(<default_port>)) and when assigning set the field to Some(SocketAddr::new(...)) instead of a bare SocketAddr; apply the same change for hpmn_list_item_b to unwrap the old port safely and wrap the new SocketAddr in Some().packages/rs-sdk-ffi/src/unified.rs (1)
368-372:⚠️ Potential issue | 🟠 MajorTest is missing the new
core_callbacksfield — will not compile.The
UnifiedSDKConfigstruct now requires acore_callbacks: FFIEventCallbacksfield (added at lines 22-23), but the test at line 368-372 does not include it. This will cause a compilation error when thecorefeature is enabled.🐛 Proposed fix
let unified_config = UnifiedSDKConfig { core_config: core_config_ptr, + core_callbacks: FFIEventCallbacks::default(), // or appropriate test callbacks platform_config, enable_integration: true, };Note: This fix assumes
FFIEventCallbacksimplementsDefault. If not, you'll need to construct an appropriate instance with the required callback function pointers.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/rs-sdk-ffi/src/unified.rs` around lines 368 - 372, The test constructs UnifiedSDKConfig without the new core_callbacks field causing a compile error; update the UnifiedSDKConfig instantiation in the test to include core_callbacks: either supply FFIEventCallbacks::default() (if Default is implemented) or construct a suitable FFIEventCallbacks value with the required callback pointers, e.g. add core_callbacks: <constructed_value> alongside core_config: core_config_ptr, platform_config and enable_integration when creating UnifiedSDKConfig.
🧹 Nitpick comments (1)
packages/rs-sdk-ffi/src/unified.rs (1)
18-28: Document the newcore_callbacksfield for FFI consumers.The addition of
core_callbacks: FFIEventCallbacksto the#[repr(C)]struct is a breaking change for FFI consumers. Consider adding a doc comment explaining the purpose of this field and how consumers should initialize it.📝 Suggested documentation
/// Unified SDK configuration combining both Core and Platform settings #[repr(C)] pub struct UnifiedSDKConfig { /// Core SDK configuration (ignored if core feature disabled) pub core_config: *const FFIClientConfig, - /// Event callbacks for core SPV client + /// Event callbacks for core SPV client. + /// These callbacks are invoked by the SPV client to notify the caller of events + /// such as sync progress, new blocks, and transaction updates. pub core_callbacks: FFIEventCallbacks, /// Platform SDK configuration pub platform_config: DashSDKConfig, /// Whether to enable cross-layer integration pub enable_integration: bool, }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/rs-sdk-ffi/src/unified.rs` around lines 18 - 28, Add a doc comment to the UnifiedSDKConfig struct that documents the new core_callbacks field: explain that core_callbacks is an FFIEventCallbacks struct pointer value consumers must populate when the core feature is enabled (or set to the default/zeroed callbacks when not used), describe expected ownership/lifetime and how it will be read by the runtime, and note compatibility impact for existing consumers; update the struct definition comment near UnifiedSDKConfig and reference the exact field name core_callbacks and the type FFIEventCallbacks so callers know how to construct/initialize it correctly for FFI usage.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/rs-sdk-ffi/src/unified.rs`:
- Line 77: The UnifiedSDKConfig initialization is missing the required
core_callbacks field and the code calls .clone() on config.core_callbacks which
may not be Clone; update the test to include core_callbacks: <appropriate
FFIEventCallbacks value> when constructing UnifiedSDKConfig and remove the
.clone() call when calling dash_spv_ffi_client_new (use config.core_callbacks
directly or pass a reference/unsafe pointer as required by
dash_spv_ffi_client_new); specifically adjust the UnifiedSDKConfig construction
and the call site where dash_spv_ffi_client_new(config.core_config,
config.core_callbacks.clone()) is used so it supplies the explicit
core_callbacks field and no clone is invoked.
---
Outside diff comments:
In `@packages/rs-drive-abci/tests/strategy_tests/masternodes.rs`:
- Around line 528-530: The HPMN IP update assumes state.service is always
present but it may be an Option; update the logic around
hpmn_list_item_b.state.service so it handles the Option case (e.g., match or map
the Option), preserving the existing port when Some(SocketAddr) and leaving None
untouched (or creating Some(SocketAddr::new(IpAddr::V4(random_ip), old_port))
only when there is an existing address). Refer to identifiers hpmn_list_item_b,
state.service, SocketAddr::new and IpAddr::V4(random_ip) when locating and
fixing the code.
- Around line 351-354: DMNState.service is an Option<SocketAddr> but the code
treats it as a bare SocketAddr; change the reads to safely extract the port
(e.g., masternode_list_item_b.state.service.as_ref().map(|s|
s.port()).unwrap_or(<default_port>)) and when assigning set the field to
Some(SocketAddr::new(...)) instead of a bare SocketAddr; apply the same change
for hpmn_list_item_b to unwrap the old port safely and wrap the new SocketAddr
in Some().
In `@packages/rs-sdk-ffi/src/unified.rs`:
- Around line 368-372: The test constructs UnifiedSDKConfig without the new
core_callbacks field causing a compile error; update the UnifiedSDKConfig
instantiation in the test to include core_callbacks: either supply
FFIEventCallbacks::default() (if Default is implemented) or construct a suitable
FFIEventCallbacks value with the required callback pointers, e.g. add
core_callbacks: <constructed_value> alongside core_config: core_config_ptr,
platform_config and enable_integration when creating UnifiedSDKConfig.
---
Nitpick comments:
In `@packages/rs-sdk-ffi/src/unified.rs`:
- Around line 18-28: Add a doc comment to the UnifiedSDKConfig struct that
documents the new core_callbacks field: explain that core_callbacks is an
FFIEventCallbacks struct pointer value consumers must populate when the core
feature is enabled (or set to the default/zeroed callbacks when not used),
describe expected ownership/lifetime and how it will be read by the runtime, and
note compatibility impact for existing consumers; update the struct definition
comment near UnifiedSDKConfig and reference the exact field name core_callbacks
and the type FFIEventCallbacks so callers know how to construct/initialize it
correctly for FFI usage.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: e076b88b-9332-4e5a-8950-c54e65f46e1c
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (17)
Cargo.tomlpackages/rs-dpp/Cargo.tomlpackages/rs-dpp/src/lib.rspackages/rs-drive-abci/src/execution/platform_events/core_based_updates/update_masternode_identities/update_operator_identity/v0/mod.rspackages/rs-drive-abci/src/execution/platform_events/core_based_updates/update_masternode_list/update_state_masternode_list/v0/mod.rspackages/rs-drive-abci/src/execution/validation/state_transition/state_transitions/mod.rspackages/rs-drive-abci/src/platform_types/masternode/mod.rspackages/rs-drive-abci/src/platform_types/masternode/v0/mod.rspackages/rs-drive-abci/src/platform_types/validator/v0/mod.rspackages/rs-drive-abci/tests/strategy_tests/masternode_list_item_helpers.rspackages/rs-drive-abci/tests/strategy_tests/masternodes.rspackages/rs-platform-wallet/Cargo.tomlpackages/rs-platform-wallet/examples/basic_usage.rspackages/rs-platform-wallet/src/lib.rspackages/rs-platform-wallet/src/platform_wallet_info/wallet_info_interface.rspackages/rs-platform-wallet/src/platform_wallet_info/wallet_transaction_checker.rspackages/rs-sdk-ffi/src/unified.rs
shumkov
force-pushed
the
chore/dashcore-08ade6e8
branch
4 times, most recently
from
c986d22 to
6099764
Compare
Codecov Report❌ Patch coverage is
❌ Your patch check has failed because the patch coverage (0.00%) is below the target coverage (50.00%). You can increase the patch coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## v3.1-dev #3408 +/- ##
============================================
- Coverage 79.93% 79.93% -0.01%
============================================
Files 2861 2861
Lines 280230 280236 +6
============================================
Hits 223993 223993
- Misses 56237 56243 +6
🚀 New features to boost your workflow:
|
shumkov
force-pushed
the
chore/dashcore-08ade6e8
branch
from
6099764 to
b435010
Compare
Contributor
There was a problem hiding this comment.
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 (2)
packages/swift-sdk/Sources/SwiftDashSDK/Core/Services/WalletService.swift (1)
165-181:⚠️ Potential issue | 🟠 MajorRecreated clients should publish a fresh progress snapshot too.
init(...)immediately callstriggerProgressUpdate(), but this path does not. AfterstopSync()/switchNetwork()/clearSpvStorage(),syncProgresscan keep the destroyed client's state until the next sync event, which makes the UI stale and can make Line 222 think sync is still running.Possible fix
self.spvClient = try! SPVClient( network: self.self.network.sdkNetwork, dataDir: dataDir, startHeight: 0, progressHandler: SPVProgressUpdateEventHandlerImpl(walletService: self), syncHandler: SPVSyncEventsHandlerImpl(walletService: self), networkHandler: SPVNetworkEventsHandlerImpl(walletService: self), walletHandler: SPVWalletEventsHandlerImpl(walletService: self) ) + self.spvClient.triggerProgressUpdate() try! self.spvClient.setMasternodeSyncEnabled(self.masternodesEnabled)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/swift-sdk/Sources/SwiftDashSDK/Core/Services/WalletService.swift` around lines 165 - 181, When re-creating SPV and wallet clients the old sync state can persist; after constructing self.spvClient and initializing self.walletManager (the same block that currently uses SPVClient(...) and CoreWalletManager(...)), force-publish a fresh progress snapshot by calling the same mechanism used in init(...), e.g. invoke triggerProgressUpdate() or explicitly reset syncProgress to the not-started state and publish it; do this immediately after the SPVClient and walletManager creation so stopSync()/switchNetwork()/clearSpvStorage() won't leave stale state visible to the UI or to code that checks syncProgress.packages/swift-sdk/Sources/SwiftDashSDK/Core/SPV/SPVEventHandler.swift (1)
218-229:⚠️ Potential issue | 🟠 MajorThe new transaction-state signals are discarded instead of forwarded to Swift handlers.
The
confirmedTxidsandconfirmedTxidCountparameters inonSpvBlockProcessedCallbackC(lines 222–223) are never used; thestatus: FFITransactionContextinonSpvTransactionReceivedCallbackC(line 433) is ignored; andon_transaction_status_changedis wired tonil(line 424). This means mempool/confirmation/InstantSend status updates from dash-spv-ffi never reach the Swift side. Add a transaction-status handler method toSPVWalletEventsHandlerand wire it before shipping mempool-status support.Also applies to: 423-425, 431-457
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/swift-sdk/Sources/SwiftDashSDK/Core/SPV/SPVEventHandler.swift` around lines 218 - 229, The callback onSpvBlockProcessedCallbackC currently ignores confirmedTxids/confirmedTxidCount—decode the confirmedTxids pointer into a Swift [Data] (using bytePtrIntoData per-entry) and forward them to a new SPVWalletEventsHandler method (e.g., onTransactionConfirmations or onTransactionStatusChanged) so block-processed events include confirmed txids; also update onSpvTransactionReceivedCallbackC to read the FFITransactionContext status parameter and call that same new handler with the transaction id and status, and stop passing nil for on_transaction_status_changed (wire the FFI callback to your Swift wrapper) so mempool/confirmation/InstantSend status updates from dash-spv-ffi reach Swift. Ensure you add the new method signature to SPVWalletEventsHandler and invoke it from both onSpvBlockProcessedCallbackC and onSpvTransactionReceivedCallbackC, preserving existing parameters like height/hash where applicable.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/rs-sdk-ffi/build_ios.sh`:
- Around line 189-219: The fallback host build may not produce
KEY_WALLET_HEADER_PATH or SPV_HEADER_PATH but later the script always writes
module.modulemap including DashSPVFFI and KeyWalletFFI entries; update the
script to either exit non‑zero when the required headers are missing (fail fast)
or conditionally include the DashSPVFFI and KeyWalletFFI module entries only
when SPV_HEADER_PATH and KEY_WALLET_HEADER_PATH exist (i.e., gate the modulemap
generation on the presence checks you already perform), ensuring
module.modulemap is consistent with the copied headers.
---
Outside diff comments:
In `@packages/swift-sdk/Sources/SwiftDashSDK/Core/Services/WalletService.swift`:
- Around line 165-181: When re-creating SPV and wallet clients the old sync
state can persist; after constructing self.spvClient and initializing
self.walletManager (the same block that currently uses SPVClient(...) and
CoreWalletManager(...)), force-publish a fresh progress snapshot by calling the
same mechanism used in init(...), e.g. invoke triggerProgressUpdate() or
explicitly reset syncProgress to the not-started state and publish it; do this
immediately after the SPVClient and walletManager creation so
stopSync()/switchNetwork()/clearSpvStorage() won't leave stale state visible to
the UI or to code that checks syncProgress.
In `@packages/swift-sdk/Sources/SwiftDashSDK/Core/SPV/SPVEventHandler.swift`:
- Around line 218-229: The callback onSpvBlockProcessedCallbackC currently
ignores confirmedTxids/confirmedTxidCount—decode the confirmedTxids pointer into
a Swift [Data] (using bytePtrIntoData per-entry) and forward them to a new
SPVWalletEventsHandler method (e.g., onTransactionConfirmations or
onTransactionStatusChanged) so block-processed events include confirmed txids;
also update onSpvTransactionReceivedCallbackC to read the FFITransactionContext
status parameter and call that same new handler with the transaction id and
status, and stop passing nil for on_transaction_status_changed (wire the FFI
callback to your Swift wrapper) so mempool/confirmation/InstantSend status
updates from dash-spv-ffi reach Swift. Ensure you add the new method signature
to SPVWalletEventsHandler and invoke it from both onSpvBlockProcessedCallbackC
and onSpvTransactionReceivedCallbackC, preserving existing parameters like
height/hash where applicable.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 79c67f3d-c81e-4a11-817b-9aa3030b4642
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (15)
Cargo.tomlpackages/rs-dpp/Cargo.tomlpackages/rs-dpp/src/lib.rspackages/rs-platform-wallet/Cargo.tomlpackages/rs-platform-wallet/examples/basic_usage.rspackages/rs-platform-wallet/src/lib.rspackages/rs-platform-wallet/src/platform_wallet_info/wallet_info_interface.rspackages/rs-platform-wallet/src/platform_wallet_info/wallet_transaction_checker.rspackages/rs-sdk-ffi/build.rspackages/rs-sdk-ffi/build_ios.shpackages/rs-sdk-ffi/include/dash_sdk_ffi.hpackages/rs-sdk-ffi/src/unified.rspackages/swift-sdk/Sources/SwiftDashSDK/Core/SPV/SPVClient.swiftpackages/swift-sdk/Sources/SwiftDashSDK/Core/SPV/SPVEventHandler.swiftpackages/swift-sdk/Sources/SwiftDashSDK/Core/Services/WalletService.swift
💤 Files with no reviewable changes (1)
- packages/rs-platform-wallet/examples/basic_usage.rs
✅ Files skipped from review due to trivial changes (1)
- packages/rs-sdk-ffi/include/dash_sdk_ffi.h
🚧 Files skipped from review as they are similar to previous changes (7)
- packages/rs-platform-wallet/Cargo.toml
- packages/rs-platform-wallet/src/lib.rs
- packages/rs-sdk-ffi/src/unified.rs
- packages/rs-dpp/src/lib.rs
- packages/rs-platform-wallet/src/platform_wallet_info/wallet_transaction_checker.rs
- packages/rs-dpp/Cargo.toml
- Cargo.toml
shumkov
force-pushed
the
chore/dashcore-08ade6e8
branch
from
b435010 to
d711c0b
Compare
shumkov
changed the title
shumkov
force-pushed
the
chore/dashcore-08ade6e8
branch
from
d711c0b to
b5441bd
Compare
thepastaclaw
suggested changes
Mar 26, 2026
Collaborator
thepastaclaw
left a comment
thepastaclaw
left a comment
There was a problem hiding this comment.
Code Review
Verified 2 blocking issues in the checked-in source. The convergent ABI finding is confirmed directly in Rust and the exported C header, and the standalone header regression is also real. I did not include the platform-wallet manager report because this checkout alone does not prove the exact upstream key-wallet API at rev 88eacdf1.
Reviewed commit: b5441bd
🔴 2 blocking
1 additional finding
🔴 blocking: UnifiedSDKConfig in the exported C header no longer matches the Rust ABI
packages/rs-sdk-ffi/include/dash_sdk_ffi.h (lines 687-694)
packages/rs-sdk-ffi/src/unified.rs:19-27 adds a new core_callbacks: FFIEventCallbacks field between core_config and platform_config, and dash_unified_sdk_create now passes config.core_callbacks into dash_spv_ffi_client_new. The checked-in header still declares UnifiedSDKConfig with only core_config, platform_config, and enable_integration, so C/Swift callers will build against the wrong struct size and field offsets.
🤖 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/include/dash_sdk_ffi.h`:
- [BLOCKING] lines 687-694: UnifiedSDKConfig in the exported C header no longer matches the Rust ABI
`packages/rs-sdk-ffi/src/unified.rs:19-27` adds a new `core_callbacks: FFIEventCallbacks` field between `core_config` and `platform_config`, and `dash_unified_sdk_create` now passes `config.core_callbacks` into `dash_spv_ffi_client_new`. The checked-in header still declares `UnifiedSDKConfig` with only `core_config`, `platform_config`, and `enable_integration`, so C/Swift callers will build against the wrong struct size and field offsets.
- [BLOCKING] lines 15-21: dash_sdk_ffi.h is no longer self-contained after removing dash_spv_ffi.h
The header comment at lines 15-21 says the file is self-contained, but it now only forward-declares `FFIClientConfig`. Later declarations still expose `FFISyncProgress *`, `FFISpvStats *`, and `FFIBalance *` (`packages/rs-sdk-ffi/include/dash_sdk_ffi.h:880-916`), and none of those typedefs are declared anywhere in this header. Any consumer including `dash_sdk_ffi.h` by itself will hit unknown-type compile errors.
Comment on lines
+15
to
+21
| /* Forward declarations for types from dash-spv-ffi. | ||
| * When building the full unified SDK, the merge step in build_ios.sh replaces | ||
| * this header with one that includes the complete dash_spv_ffi.h definitions. | ||
| * These forward declarations keep the header self-contained for local use. */ | ||
| #ifndef DASH_SPV_FFI_H | ||
| typedef struct FFIClientConfig FFIClientConfig; | ||
| #endif |
Collaborator
There was a problem hiding this comment.
🔴 Blocking: dash_sdk_ffi.h is no longer self-contained after removing dash_spv_ffi.h
The header comment at lines 15-21 says the file is self-contained, but it now only forward-declares FFIClientConfig. Later declarations still expose FFISyncProgress *, FFISpvStats *, and FFIBalance * (packages/rs-sdk-ffi/include/dash_sdk_ffi.h:880-916), and none of those typedefs are declared anywhere in this header. Any consumer including dash_sdk_ffi.h by itself will hit unknown-type compile errors.
source: unknown
🤖 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/include/dash_sdk_ffi.h`:
- [BLOCKING] lines 15-21: dash_sdk_ffi.h is no longer self-contained after removing dash_spv_ffi.h
The header comment at lines 15-21 says the file is self-contained, but it now only forward-declares `FFIClientConfig`. Later declarations still expose `FFISyncProgress *`, `FFISpvStats *`, and `FFIBalance *` (`packages/rs-sdk-ffi/include/dash_sdk_ffi.h:880-916`), and none of those typedefs are declared anywhere in this header. Any consumer including `dash_sdk_ffi.h` by itself will hit unknown-type compile errors.
b5441bd to
fd5e029
Compare
Contributor
|
✅ 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: "3b3fb3d624a293ef533d19d98bc687b1d48c8d08da35214a3b39145643d9712d"
)Xcode manual integration:
|
shumkov
force-pushed
the
chore/dashcore-08ade6e8
branch
3 times, most recently
from
f740039 to
8883e82
Compare
…t-manager) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
shumkov
force-pushed
the
chore/dashcore-08ade6e8
branch
from
8883e82 to
7db14fa
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue being fixed or feature implemented
Update rust-dashcore dependency from
8cbae416to08ade6e8(v0.42-dev HEAD). Brings mempool support, EventHandler pattern, TransactionContext restructure, and wallet event improvements.What was done?
08ade6e8key-wallet-managerfrom workspace deps (merged intokey-wallet::manager)"std"feature from dashcore dep in rs-dpp (removed upstream)key-wallet-managerimports →key_wallet::managerin rs-dpp and rs-platform-walletDMNState.service→Option<SocketAddr>: keepMasternodeStateV0.serviceasSocketAddr, changeFromtoTryFromwith error when service is NoneWalletTransactionCheckersignature: addupdate_balanceparammark_instant_send_utxosandmonitor_revisionto WalletInfoInterface implrs-sdk-ffi/unified.rs: passFFIEventCallbackstodash_spv_ffi_client_newHow Has This Been Tested?
cargo check -p dpp --all-featurespassescargo check -p drive -p wasm-dpp -p simple-signer -p platform-valuepassesBreaking Changes
key-wallet-managercrate no longer exists — usekey_wallet::managerDMNState.serviceis nowOption<SocketAddr>— requires-deprecatedrpc=serviceflag on Core v24+WalletInterface::process_mempool_transactionsignature changedDashSpvClient::newtakes EventHandler parameterSummary by CodeRabbit
Chores
New Features
Bug Fixes