THRIFT-5953: Rust codegen forward-compatible union deserialization in structs

[santiagomed]

Problem

When a struct contains a union-typed field and the wire data has a union variant (field ID) not present in the local IDL, the generated Rust code fails to deserialize the entire struct — not just the unknown union field.

The root cause: the union's read_from_in_protocol correctly returns Err("received empty union") for unknown variants (fixed in PR #3336). But the parent struct's generated deserializer propagates this error via ?, causing the whole struct to fail.

This breaks Thrift's forward-compatibility guarantee. When a server adds a new union variant, all clients running an older IDL version fail to parse any message containing that variant — even though the client doesn't need to understand the new variant to process the rest of the struct.

Java, Go, Python, and C++ Thrift all handle this gracefully: unknown union variants are silently skipped, and the struct field is left unset.

Fix

In render_struct_sync_read, detect struct fields whose type is a union. For those fields, wrap the read_from_in_protocol call in a match that catches the "received empty union" error and treats it as None (field absent):

// Before (all fields):
let val = FooUnion::read_from_in_protocol(i_prot)?;
f_N = Some(val);

// After (union fields only):
match FooUnion::read_from_in_protocol(i_prot) {
    Ok(val) => { f_N = Some(val); },
    Err(thrift::Error::Protocol(ref e))
        if e.message.contains("received empty union") => {
        // forward compatibility: unknown union variant skipped
    },
    Err(e) => return Err(e),
}

Non-union fields are unchanged. The union's own TSerializable impl is unchanged — it still returns Err for unknown variants, preserving the contract for callers that read unions directly.

Impact

• Fixes forward compatibility for all Rust Thrift users with evolving union schemas
• No changes to the TSerializable trait or the thrift runtime library
• No changes to the union`s own serialization/deserialization
• Struct fields with union types that receive unknown variants get None instead of causing parse failure
• All other errors (malformed data, I/O, multiple union fields) still propagate normally

[Jens-G]

BTW We still look for Rust maintainers as the previous one got lost somehow.

[Jens-G]

Commits on Apr 22, 2026
THRIFT-XXXX: Rust codegen: forward-compatible union deserialization in structs

We have rules about AI generated content. Acrtually in the codebase. And THRIFT-XXXX is not a valid number.

[Jens-G]

Two more suggestions:

• Having at least one integration test would be great
• This change indeed deserves a JIRA ticket. It is a non-trivial codegen change so we should have one.

Thank you for your contribution!

[Jens-G]

I would consider that string search a code smell. What about adding a dedicated ProtocolErrorKind variant? Similar to ProtocolErrorKind::InvalidData for the "empty union" case around line 1837.

[santiagomed]

I added ProtocolErrorKind::EmptyUnion = 7 to the runtime library and updated both sides of the codegen to use it. The union deserializer now emits EmptyUnion instead of InvalidData, and the struct-level catch arm matches on e.kind == ProtocolErrorKind::EmptyUnion instead of the string check. Also added an integration test covering the unknown variant path.

[santiagomed]

@Jens-G thanks for the review. Will apply these changes.

Also, I am happy to take on as maintainer - we at xAI use Rust + Thrift quite a bit in production and need active support. Let me know what's needed

EDIT: I requested a Jira account for the apache thrift project to create the ticket and apply as maintainer.

[santiagomed]

@Jens-G created a Jira ticket: https://issues.apache.org/jira/projects/THRIFT/issues/THRIFT-5953?filter=allopenissues

[kpumuk]

This looks like a large change, and the fact we have tests disabled on CI does not inspire confidence. @santiagomed would it make sense to create a separate pull request to enable back lib-rust and integration tests for Rust (making sure they pass) before merging this one?

See e4666f2