fix(sync): return error instead of panicking on get_account proof with no details - #2502
fix(sync): return error instead of panicking on get_account proof with no details#2502erhnysr wants to merge 3 commits into
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0678b19849
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| * [FIX][rust] The RPC retry policy is now endpoint-aware: `SubmitProvenTransaction` and `SubmitProvenBatch` retry only `ResourceExhausted` and let `Unavailable` propagate, while read endpoints keep retrying both. `Unavailable` does not say whether the node processed the request, so resubmitting could hit the nullifier consumed by an accepted copy and report a conflict indistinguishable from a genuine double spend, hiding the original success ([#2441](https://github.com/0xMiden/rust-sdk/issues/2441)). | ||
| * [FIX][cli] `-V`/`--version` now work when the binary is invoked under a different name, such as through the `miden client` shim installed by midenup ([#2486] https://github.com/0xMiden/rust-sdk/pull/2486)). | ||
| <!-- TODO: update the PR link below to the actual PR number once the PR is opened (currently a placeholder). --> | ||
| * [FIX][rust] `StateSync::validate_account_proof` now returns a `ChainValidationError` when a `get_account` proof carries no account details, instead of panicking. The RPC layer allows the details to be absent, so a malformed or malicious node response could crash the client mid-sync ([#XXXX](https://github.com/0xMiden/rust-sdk/pull/XXXX)). |
There was a problem hiding this comment.
Replace the placeholder changelog PR link
This checked-in Unreleased entry still links to #XXXX and is preceded by an explicit TODO, so any release notes generated before a manual follow-up will publish an invalid reference rather than the change's PR. Replace the placeholder with the actual PR number before merging.
Useful? React with 👍 / 👎.
igamigo
left a comment
There was a problem hiding this comment.
Leaving some comments. Also, can you resolve conflicts?
…oof with no details StateSync::validate_account_proof unwrapped the optional account details with expect(), treating their presence as an invariant. The RPC conversion layer allows details to be None end-to-end, so a malformed or malicious node response could crash the client mid-sync instead of surfacing a validation error. Return ClientError::ChainValidationError when details are absent, matching the function's other validation failures. Closes 0xMiden#2386
7666cd9 to
888100d
Compare
|
Hi @igamigo — Integration tests failed on Could you re-run the Integration tests job when you get a chance? (Fork PR workflows need maintainer approval to re-run.) Also addressed both your review comments in the latest commits (888100d) — replying on those threads separately. |
Summary
StateSync::validate_account_proofunwrapped the optional account details from aget_accountproof with.expect("node returned no details for a public account"), treating their presence as an invariant. ButAccountProofallowsdetails: Noneend-to-end — the RPC conversion layer inrpc/domain/account.rsproducesNonewhen the response omits them — so a malformed, buggy, or malicious node response crashes the client with a panic mid-sync instead of surfacing a validation error.This is the same class of untrusted-input hardening as the recent
VerifyingRpcClientfixes (#2419, #2381): a value the node controls was trusted without being checked.The bug
crates/rust-client/src/sync/state_sync.rsReachable during public account sync: the proof reaches
validate_account_proof, passes the block / account-id / witness checks, then panics on the final.expect()ifdetailsisNone.The fix
Return
ClientError::ChainValidationErrorwhen details are absent, consistent with the function's other validation failures:The
# Panicsdoc section is replaced with a fourth# Errorsbullet, and a regression test (validate_account_proof_rejects_missing_details) builds an otherwise-honest proof with the details stripped and assertsChainValidationError.Verification
make lint— clean (cargo fix,cargo +nightly fmt,taplo fmt,cargo clippy --workspace --features "testing std" --all-targets -- -D warnings,cargo shearall pass, no warnings)make test— 458 tests run: 458 passed, 2 skipped; the new regression test passesCloses #2386