fix(platform-wallet): poll platform-address transfer FFI on the big-stack worker#3989
Conversation
…tack worker platform_address_wallet_transfer polled its proof-verifying future with runtime().block_on on the caller's thread — the same GroveDB proof-verification recursion class runtime.rs warns about, which overflows the ~512KB stacks of iOS dispatch / Swift-concurrency threads with EXC_BAD_ACCESS after the funds moved but before the changeset reached the caller. The sibling withdraw entry points were fixed the same way in #3923; this brings the last platform-address spend path onto block_on_worker, cloning the wallet out of handle storage first so the storage read lock also releases before network work. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ 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 |
|
✅ Review complete (commit 091b53f) |
There was a problem hiding this comment.
Code Review
PR #3989 is a focused, single-file FFI fix moving platform_address_wallet_transfer off runtime().block_on on the caller's small-stack thread onto block_on_worker (8 MB worker stack), matching the established pattern used by other spend paths. The wallet is cloned out of handle storage before the long network+proof-verification round-trip so the storage read lock releases early, and the signer pointer is round-tripped through usize to satisfy Send + 'static — a pattern proven safe elsewhere in the crate since block_on_worker synchronously blocks the caller. No in-scope defects were found by any reviewer.
Source: reviewers: opus (general), claude-sonnet-5 (general), gpt-5.5[high] (general, failed_or_unparseable), opus (ffi-engineer), claude-sonnet-5 (ffi-engineer), gpt-5.5[high] (ffi-engineer, failed_or_unparseable); verifier: opus; specialists: ffi-engineer
Issue being fixed or feature implemented
platform_address_wallet_transferpolls its proof-verifying future withruntime().block_onon the caller's thread. The transfer future verifies the execution proof, and GroveDB proof verification recurses past the ~512 KB stacks of iOS dispatch / Swift-concurrency threads — the exactEXC_BAD_ACCESSclassruntime.rsdocuments — crashing after the funds moved on-chain but before the changeset reached the caller. The sibling withdraw entry points get the same fix in #3923; this covers the last platform-address spend path.What was done?
Mirror the established pattern (
fund_from_asset_lock,identity_top_up, the #3923 withdraw fix): clone the wallet out of handle storage (releasing the storage read lock before network work), round-trip the signer pointer throughusizeso the future isSend + 'static, and poll viablock_on_workeron the 8 MB-stack worker.How Has This Been Tested?
cargo check -p platform-wallet-ffiandcargo fmt --all -- --checkclean. No signature changes — no header regen or Swift-side changes needed. The identical pattern is exercised by the sibling flows' existing coverage.Breaking Changes
None.
Checklist:
🤖 Generated with Claude Code