Description
Expected Behavior
A caller that adds a key with an identity update can tell later, including after the app was killed mid-call, whether that exact signed transition landed or can no longer land.
Current Behavior
update_identity_with_external_signer returns Result<(), _>. It builds the transition from the wallet's cached identity, bumping the cached revision, and reports neither the revision nor the transition it signed. The Swift wrapper updateIdentity returns nothing either.
A caller that must survive a restart, such as DashConnect one-QR registration in dashwallet-ios, therefore records a predicted revision (cached revision + 1) before the call. If the cached identity moves between the caller's read and the SDK's snapshot (a reload, or an update from another device), the signed transition carries a higher revision than the one recorded. After a restart the caller sees the identity at the recorded revision without the key, decides the update can no longer land, and drops its record. The update can then land, leaving a live key the caller no longer knows about.
Possible Solution
Settle the outcome from the signed transition, not from a revision guess, as agreed when the revision pin was dropped from #5487:
- persist the signed transition (or its hash) in platform-wallet before it is broadcast — a broadcast outbox;
- return a handle to it (for example a broadcast id) from the update call;
- let the caller ask after a restart whether that transition landed, is still pending, or can no longer land, using the existing result/proof path.
#5556 (keeping uncertain submission results within one call) is a prerequisite for the in-call part; it does not cover a restart.
Steps to Reproduce
Not reproducible naturally on demand: it needs the identity's cached revision to change between the caller's read and the SDK snapshot, and the process to end after the broadcast and before its result. The window is visible in the code above.
Context
- App side: dashwallet-ios chore(drive): downgrade grovedb to supported version #1202, review thread feat(dashpay): sign in to an app with one DashConnect QR from protocol 14 dashwallet-ios#1202 (comment),
TODO(app-connect-broadcast-outcome). - Related: fix(platform-wallet): keep the cached identity in step with the chain around updates #5487 (revision pin dropped before merge), fix(sdk): preserve uncertain submission outcomes through shared broadcast #5556, rs-sdk: put_to_platform_and_wait_* fails with AlreadyExists when a timed-out broadcast was already accepted #4998.
- DashConnect is off on mainnet.
Your Environment
platform 5b89fe8b52 (dashwallet-ios develop pin), testnet.
Activity