Skip to content

fix(sdk)!: preserve uncertain submission results for recovery - #5556

Draft
llbartekll wants to merge 3 commits into
codex/protocol-compatibilityfrom
codex/submission-recovery
Draft

llbartekll wants to merge 3 commits into
codex/protocol-compatibilityfrom
codex/submission-recovery

Conversation

@llbartekll

@llbartekll llbartekll commented Oct 23, 2026 •

Copy link
Copy Markdown
Contributor

Issue being fixed or feature implemented

A state transition can be accepted even when the client loses the broadcast acknowledgement. Preserve that uncertainty and wait for the result of the same signed transaction instead of treating the timeout or AlreadyExists response as a reason to prepare a replacement.

What was done?

This draft extracts the existing submission/recovery work from #5511. It is stacked on codex/protocol-compatibility; review the recovery-only diff against that branch. It does not expand the previously implemented scenarios.

  • Retain dispatched transport uncertainty across ordinary retries, then wait for the existing signed transition's verified result.
  • Preserve the unconfirmed-result classification through SDK/wallet FFI, with Swift/Kotlin mappings and the existing WASM error conversion. Existing error codes remain unchanged; added codes identify this outcome.
  • Preserve top-up propagation and existing controlled-transport/proof tests. No replacement asset lock or new spending path is introduced.

The minimal protocol-observation API is in #5511. No additional compatibility state machine or write permission mechanism is added here. Unrelated pre-existing withdrawal/proof semantics remain outside this extraction.

Review items carried forward

The extraction does not claim to resolve the earlier nonblocking recommendations for a dedicated WASM error kind or a machine-readable DAPI refusal marker. Both would broaden the API/transport contract and remain outside the authorized scope.

How Has This Been Tested?

  • The stacked branch now includes the base SDK empty-epoch regression correction at 48490f211b2004e27e656019a41b14fbb4c56815. Only the same Swift closure changed; no recovery behavior, Rust or ABI change. The deterministic production-method harness passes 5/5 cases against this stack. Native framework/checksum evidence below remains from the stated pre-correction native SHA; binaries were not rebuilt for this Swift-only change.

On extracted commit 0aeb8d9d10cf734accb76969b3505a4a9f150340, 258 Rust tests pass: SDK transitions75, DAPI157, SDK FFI errors20 and wallet FFI topup6. Rustfmt and all-features/all-targets Clippy for the five affected crates pass. Kotlin error-mapper tests (26) pass, and the Kotlin GitHub build/tests job succeeds. The companion wallet draft dashpay/dashwallet-ios#1239 has passed 72 isolated Swift tests plus post-stack preparation/controller checks.

Device + arm64 simulator framework and SwiftExampleApp (warnings as errors) pass at SDK 0aeb8d9d10cf734accb76969b3505a4a9f150340; clean dashpay arm64 simulator build passes at iOS e0883216d18a4fcff7c938e8708f5ff746d59304. Both native archives and the app embed the expected SDK SHA. Framework SHA-256: 33727890ee0b442c22fc914eef2bee7385946f0e54ad11f04969c419cd9b0802 (whole POSIX relative-path strings in lexicographic order + NUL + file bytes + NUL); generated framework is not committed.

No new live funds have been spent during the split. Historical transfer evidence from the old PR does not certify these new commits.

Breaking Changes

New enum variants for the unconfirmed-result outcome may require downstream exhaustive matches to add an arm. Kotlin/WASM/Swift mappings in this repository are included. Existing C structures and numeric error codes are preserved.

In-place changes to shipped generations

None. Client submission/wait orchestration only; no consensus or protocol table changes.

Checklist:

  • I have performed a self-review of the extraction
  • My Rust, FFI, WASM, Swift or Kotlin changes follow the coding conventions
  • I have commented hard-to-understand areas
  • I have retained relevant unit/integration tests
  • Local validation of the extracted stack is complete

Draft for separate review. Scope is frozen: reviewer or bot suggestions extending scenarios/mechanisms require a separate user decision.

@coderabbitai

coderabbitai Bot commented Oct 23, 2026

Copy link
Copy Markdown
Contributor

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

  • Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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.

@thepastaclaw

thepastaclaw commented Oct 23, 2026 •

Copy link
Copy Markdown
Collaborator

🕓 Review not started yet because this PR is a draft.

  • Request normal review — click when the PR is ready for review.
  • Request priority review — click to move this review to the front of the queue.

Commit 48490f2. Normal review starts when eligible; priority review starts as soon as a slot is available.

This branch has not been deployed

No deployments
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.

2 participants