v0.5.0 — MQTT Protocol Bindings

Highlights

0.5.0 adds protocol bindings to asyncapi-rust, starting with MQTT. You can now declare MQTT server, operation, and message bindings directly in your derive attributes, and they flow through to the generated AsyncAPI 3.0 spec.

#[asyncapi_server(
    name = "production",
    host = "mqtt.example.com",
    protocol = "mqtt",
    mqtt(client_id = "svc", clean_session = false, keep_alive = 60)
)]
#[asyncapi_operation(
    name = "publishReading", action = "send", channel = "sensors",
    mqtt(qos = 2, retain = true, message_expiry_interval = 300)
)]

See examples/mqtt_bindings.rs for a full server/operation/message example.

⚡ Features

• MQTT protocol bindings for servers, operations, and messages (#12, partially addresses #11). Covers client_id, clean_session, keep_alive, session_expiry_interval, maximum_packet_size, last_will, qos, retain, message_expiry_interval, payload_format_indicator, content_type, response_topic, correlation_data, and binding_version.

🐛 Bug Fixes

• Malformed #[asyncapi(...)] / mqtt(...) attributes now fail fast with a compile error instead of being silently dropped (#14). Previously a last_will missing a required sub-field, or a value of the wrong literal type, was swallowed.

⚠️ Breaking change / Migration

Server, Operation, and Message each gained a bindings field. It is Option<_> with #[serde(default)] and Default, so deserialization, ..Default::default(), and read-only access are unaffected.

If you construct any of these structs with an explicit struct literal (e.g. in tests or a custom spec builder), add the new field:

let server = asyncapi_rust::Server {
    // ...existing fields...
    bindings: None,
};

See the "Migrating from 0.4.x" section in the README for details.

New Contributors

• @pureions (Max Christoph) made their first contribution in #12 — thank you! 🎉

Full Changelog: v0.4.0...v0.5.0