Bug affecting use of #[contractevent(data_format="vec")] in soroban-sdk >= 23.0.0, <= 23.4.0

[leighmcculloch]

A bug has been found in the contractevent attribute macro when the data_format is specified as "vec" affecting soroban-sdk versions in the range >= 23.0.0, <= 23.4.0, where the order of data fields¹ are published into the contract event data field’s Vec in lexicographical order² rather than in the order defined in the event.

The bug only occurs:

• when contractevent is used with data_format = "vec"
• when there are more than one data field in the contract event type
• when the data fields are defined in the contract event type in an order that is not lexicographically sorted

Published events are not observable by contracts and so this bug is not observable by contracts and only by off-chain systems.

A fix is underway and will be announced in this discussion topic once released.

Software: soroban-sdk
Affected Versions: 23.4.0, 23.3.0, 23.2.1, 23.1.1, 23.1.0, 23.0.3, 23.0.2, 23.0.1, 23.0.0
Affected Unstable Versions: 25.0.0-rc.1
Fixed Version: 23.4.1, 25.0.0-rc.2
Issue: stellar/rs-soroban-sdk#1679

¹ A data field is a field without a #[topic] attribute.
² Lexicographical order is also known as dictionary order, or alphabetical order.

Example

For example, the following contract event definition is affected.

The event defines its data fields to be formatted in a vec and should be published in the order they are defined: data = [data_b, data_a]

The event will be published with: data = [data_a, data_b].

#[contractevent(data_format = "vec")]
pub struct MyEvent {
    #[topic]
    pub topic: u32,
    // Fields not marked as topics will appear in the events data section.
    pub data_b: u32,
    pub data_a: u64,
}

Testing Event Publishing

Event publishing can be tested in contracts, and subsequently the bug can be verified, by implementing a test similar to the below:

#![no_std]
use soroban_sdk::{contract, contractevent, symbol_short, testutils::Events, vec, Env, IntoVal};

#[contract]
struct Contract;

#[contractevent(data_format = "vec")]
struct MyEvent {
    #[topic]
    pub topic: u32,
    // Fields not marked as topics will appear in the events data section.
    // Should be in order [b, a]
    pub data_b: u32,
    pub data_a: u64,
}

#[cfg(test)]
mod test {
    #[test]
    fn test() {
        let env = Env::default();

        let contract_id = env.register(Contract, ());

        env.as_contract(&contract_id, || {
            let event = MyEvent {
                topic: 1,
                data_b: 2,
                data_a: 3,
            };
            event.publish(&env);
        });

        assert_eq!(
            env.events().all(),
            vec![
                &env,
                (
                    contract_id.clone(),
                    // Topics:
                    (symbol_short!("my_event"), 1u32).into_val(&env),
                    // Data (with data_format as vec, order should be declaration order):
                    (
                        3u64, // BUG: data_a sorted into first pos based on the field name data_a
                        2u32, // BUG: data_b sorted into second pos based on the field name data_b
                    ).into_val(&env),
                ),
            ]
        );
    }
}

Affected Contracts on mainnet

There are five affected contracts on mainnet at the time of this post known by inspecting the available contract specs visible in a recent archive checkpoint:
https://github.com/leighmcculloch/contract-wasms/blob/main/analysis/find_event_1679_results.csv

[leighmcculloch]

A fix has been released in 23.4.1.