Send and receive messages via Azure Service Bus in Rust

This skill covers the official azure_messaging_servicebus Rust crate for Azure Service Bus - queue-based point-to-point messaging with competing consumers, and publish-subscribe messaging via topics and subscriptions. It is explicitly early-development and warns against production use since APIs may change without notice, and insists on using only the official crates.io azure-sdk-published crate, underscore-named, noting that no official release currently carries version 0.21.0 as a way to spot an unofficial or spoofed package. Core concepts include a namespace container for all messaging components, queues for point-to-point delivery, topics for one-sender-many-subscriber fan-out, subscriptions that receive from a topic, and messages carrying data and metadata with completion or abandon settlement semantics. Authentication uses DeveloperToolsCredential for local development or ManagedIdentityCredential for production, since Rust has no single DefaultAzureCredential type unlike other Azure SDKs, connecting via a ServiceBusClient builder that opens against a namespace and credential. Core workflows cover sending a message to a queue or topic by creating a sender and calling send_message, receiving messages from a queue by creating a receiver and calling receive_messages, then calling complete_message on each one after successful processing to remove it and prevent redelivery, and receiving from a topic subscription through a dedicated receiver-for-subscription call. RBAC for Entra ID authentication requires one of three data-plane roles: Service Bus Data Sender, Data Receiver, or Data Owner for full access.

Use it when a Rust application needs to send or receive messages via Azure Service Bus - queue-based messaging with competing consumers, or publish-subscribe messaging with topics and subscriptions - triggered by phrases like "service bus rust" or "queue rust messaging." Given its pre-production warning, treat it as unsuitable for production workloads without independently verifying current API stability, and pin the dependency version explicitly rather than tracking latest.

Given a namespace and credential, it produces a connected ServiceBusClient plus senders and receivers scoped to a queue, topic, or subscription; sending produces a delivered message, receiving produces a batch of messages that must each be explicitly completed or abandoned afterward.

cargo add azure_messaging_servicebus azure_identity tokio

Requires azure_identity for credentials and tokio for the async runtime; azure_core is only needed as a direct dependency if importing its types, such as Url, RequestContent, or ErrorKind, directly rather than through azure_messaging_servicebus re-exports. A SERVICEBUS_NAMESPACE environment variable holding the fully qualified namespace is required. Dependencies should be managed with cargo add and cargo commands rather than manual Cargo.toml edits, and credentials should never be hardcoded - use environment variables or managed identity instead.

Rust developers building message-driven applications on Azure Service Bus who need queue or publish-subscribe messaging with reliable completion semantics - understanding this crate is pre-production and requires careful version pinning and independent verification before any production use.