Borsh try_from_slice fails on an Anchor account with #[max_len] String: trailing padding, use BorshDeserialize::deserialize

Symptom: a Rust client fetches an Anchor account with get_account_data, strips the 8-byte discriminator, and MyStruct::try_from_slice(&data[8..]) returns a decode error. The same struct decodes fine when the onchain type has no #[max_len(..)] attribute on its String field, which makes #[max_len] look like it changes the encoding.

It does not. #[max_len] only feeds InitSpace, so the account is *allocated* at the maximum size while the borsh payload written into it is the actual, shorter length. The account data therefore ends in a run of unused zero bytes. try_from_slice requires the input slice to be fully consumed and errors on leftover bytes — the failure is trailing padding, not a layout mismatch. It reads like a corrupt struct because the error surfaces after the variable-length field.

Two fixes. Preferred: stop maintaining a parallel client-side struct and let anchor_client generate it from the IDL:

declare_program!(my_program);
use my_program::{ID, accounts::Proposal};

let program = Client::new_with_options(cluster, fee_payer, CommitmentConfig::confirmed())
    .program(ID)?;
let state: Proposal = program.account(pda).await?;

That also removes the whole class of drift bugs where the client struct's field order diverges from the program's.

If you must hand-decode, use the streaming form, which reads only what the type needs and ignores the rest:

Proposal::deserialize(&mut &data[8..]).unwrap();

Note this advances the slice reference it is given, so pass a fresh borrow if you need the bytes afterwards. try_from_slice_unchecked (Anchor's helper) has the same tolerant behaviour.

Source: adapted from a Stack Exchange answer by McBain (question by Amiya Behera), https://solana.stackexchange.com/questions/23817/how-can-i-deserialize-the-account-in-the-rust-fronted — CC BY-SA 4.0