Skip to content

Handle malformed XDR in the address conversion example - #2849

Open
devtechedge wants to merge 2 commits into
stellar:mainfrom
devtechedge:fix/address-from-xdr-malformed-input
Open

Handle malformed XDR in the address conversion example#2849
devtechedge wants to merge 2 commits into
stellar:mainfrom
devtechedge:fix/address-from-xdr-malformed-input

Conversation

@devtechedge

Copy link
Copy Markdown

Fixes #2768.

Summary

The smart-contract example on the address conversions guide called Address::from_xdr(&env, &bytes).unwrap(), which panics when the bytes do not contain a valid Address value.

This PR changes the example to return the fallible result directly (Result<Address, ConversionError>) and adds a short note in the surrounding prose: contracts that receive XDR bytes from untrusted sources, such as a custom authentication scheme, should handle the error case instead of unwrapping, since malformed input is a normal condition at a trust boundary.

Testing

Docs-only change to one guide page. The Rust snippet mirrors the FromXdr trait signature in soroban-sdk (fn from_xdr(env: &Env, b: &Bytes) -> Result<Self, Self::Error>, with Address's conversion error being ConversionError).

Address::from_xdr is fallible, so the smart-contract example now returns Result<Address, ConversionError> instead of unwrapping, and the prose notes that untrusted bytes should be handled at the trust boundary.

Fixes stellar#2768
Copilot AI balanced review requested due to automatic review settings September 11, 2026 18:48

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Updates the address-conversion guide to promote fallible XDR decoding at trust boundaries.

Changes:

  • Returns Result<Address, ConversionError>.
  • Adds malformed-input guidance.
  • However, FromXdr itself still panics on malformed XDR, so the issue remains unresolved.

Recommendation: NEEDS-CHANGES — provide a genuinely non-panicking decoding path or accurately document the limitation.


💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread docs/build/guides/conversions/address-conversions.mdx
…xample

FromXdr::from_xdr returns Err only when the bytes deserialize to a valid
ScVal of a different type. Bytes that are not valid ScVal XDR at all
panic before a Result is produced, and the SDK offers no in-contract
recovery for that case. The prose now documents both failure modes and
recommends validating untrusted input before it reaches the contract,
or preferring typed arguments such as Address.
Copilot AI review requested due to automatic review settings September 11, 2026 19:00

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (1)

docs/build/guides/conversions/address-conversions.mdx:125

  • This still does not handle the malformed-XDR case named in the PR and issue. In the current SDK, from_xdr calls deserialize_from_bytes(...).unwrap_infallible(), so malformed bytes panic before this Result can be returned; only valid ScVal XDR of the wrong type produces ConversionError. Client-side validation also cannot protect a public contract boundary because another caller can bypass it. Please either restrict this helper and its guidance to trusted bytes (requiring a typed Address for caller-controlled input), or show a complete in-contract validation strategy before decoding.
pub fn address_from_xdr_bytes(env: Env, bytes: Bytes) -> Result<Address, ConversionError> {
    Address::from_xdr(&env, &bytes)

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.

Handle malformed XDR in the smart-contract address conversion example

2 participants