Send and receive messages via Azure Service Bus in Rust
A Rust skill for Azure Service Bus - queue and topic/subscription messaging via the official (pre-production) crate.
Why it matters
Enable Rust applications to reliably send and receive messages through Azure Service Bus queues, topics, and subscriptions with enterprise-grade message broker capabilities and completion semantics.
Outcomes
What it gets done
Send messages to Azure Service Bus queues or topics from Rust code
Receive and process messages from queues with competing consumers
Subscribe to topics and handle publish-subscribe messaging patterns
Complete or abandon messages with proper settlement semantics
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-azure-servicebus-rust | bash Overview
Azure Service Bus library for Rust
This skill covers the official pre-production azure_messaging_servicebus Rust crate: sending/receiving via queues and topic subscriptions, message completion semantics, and Entra ID authentication with RBAC roles. Use it when a Rust app needs Azure Service Bus queue or pub-sub messaging. The crate is explicitly not production-ready - verify API stability and pin the version.
What it does
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.
When to use - and when NOT to
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.
Inputs and outputs
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.
Integrations
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.
Who it's for
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.
Source README
Azure Service Bus library for Rust
When to Use
Use this skill when you need azure Service Bus library for Rust. Send and receive messages using queues, topics, and subscriptions. Triggers: "service bus rust", "ServiceBusClient rust", "send message servicebus rust", "receive message servicebus rust", "queue rust messaging", "topic subscription rust".
Client library for Azure Service Bus - enterprise message broker with queues and publish-subscribe topics.
⚠️ WARNING: This crate is in early development and SHOULD NOT be used in production. APIs may change without notice.
Use this skill when:
- An app needs to send or receive messages via Azure Service Bus from Rust
- You need queue-based messaging with competing consumers
- You need publish-subscribe messaging with topics and subscriptions
- You need reliable message delivery with completion semantics
IMPORTANT: Only use the official
azure_messaging_servicebuscrate published by the azure-sdk crates.io user. Do NOT use unofficial or community crates. Official crates use underscores in names and none have version 0.21.0.
Installation
cargo add azure_messaging_servicebus azure_identity tokio
If your code uses
azure_coretypes directly, addazure_coretoCargo.toml. If you only useazure_messaging_servicebusre-exports, directazure_coredependency is optional.
Environment Variables
SERVICEBUS_NAMESPACE=<namespace>.servicebus.windows.net # Required — fully qualified namespace
Key Concepts
| Concept | Description |
|---|---|
| Namespace | Container for all messaging components |
| Queue | Point-to-point messaging with competing consumers |
| Topic | Publish-subscribe messaging - one sender, many subscribers |
| Subscription | Receives messages from a topic |
| Message | Package of data and metadata, with completion/abandon semantics |
Authentication
use azure_identity::DeveloperToolsCredential;
use azure_messaging_servicebus::ServiceBusClient;
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
// Local dev: DeveloperToolsCredential. Production: use ManagedIdentityCredential.
let credential = DeveloperToolsCredential::new(None)?;
let client = ServiceBusClient::builder()
.open("your_namespace.servicebus.windows.net", credential.clone())
.await?;
Ok(())
}
Core Workflow
Send a Message to a Queue
use azure_identity::DeveloperToolsCredential;
use azure_messaging_servicebus::{ServiceBusClient, Message};
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
let credential = DeveloperToolsCredential::new(None)?;
let client = ServiceBusClient::builder()
.open("your_namespace.servicebus.windows.net", credential.clone())
.await?;
let sender = client.create_sender("my_queue", None).await?;
let message = Message::from("Hello, Service Bus!");
sender.send_message(message, None).await?;
Ok(())
}
Receive Messages from a Queue
use azure_identity::DeveloperToolsCredential;
use azure_messaging_servicebus::ServiceBusClient;
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
let credential = DeveloperToolsCredential::new(None)?;
let client = ServiceBusClient::builder()
.open("your_namespace.servicebus.windows.net", credential.clone())
.await?;
let receiver = client.create_receiver("my_queue", None).await?;
let messages = receiver.receive_messages(5, None).await?;
for message in messages {
println!("Received: {}", message.body_as_string()?);
receiver.complete_message(&message, None).await?;
}
Ok(())
}
Send a Message to a Topic
let sender = client.create_sender("my_topic", None).await?;
let message = Message::from("Hello, Topic subscribers!");
sender.send_message(message, None).await?;
Receive Messages from a Subscription
let receiver = client
.create_receiver_for_subscription("my_topic", "my_subscription", None)
.await?;
let messages = receiver.receive_messages(5, None).await?;
for message in messages {
println!("Received: {}", message.body_as_string()?);
receiver.complete_message(&message, None).await?;
}
Message Settlement
| Action | Purpose |
|---|---|
complete |
Remove message from queue - processing succeeded |
abandon |
Release lock - message becomes available for retry |
Always complete messages after successful processing to prevent redelivery.
RBAC Roles
For Entra ID auth, assign one of these roles:
| Role | Access |
|---|---|
Azure Service Bus Data Sender |
Send messages |
Azure Service Bus Data Receiver |
Receive messages |
Azure Service Bus Data Owner |
Full access |
Best Practices
- Use
cargo addto manage dependencies, never editCargo.tomldirectly. Add and remove Rust SDK dependencies with cargo commands instead of manual manifest edits. - Add
azure_coreonly when importingazure_coretypes directly. If your code importsazure_core::http::Url,azure_core::http::RequestContent, orazure_core::error::ErrorKind, includeazure_core; otherwise a direct dependency is optional. - Use
DeveloperToolsCredentialfor local dev,ManagedIdentityCredentialfor production - Rust does not provide a singleDefaultAzureCredentialtype - Never hardcode credentials - use environment variables or managed identity
- Assign RBAC roles - ensure the identity has appropriate Service Bus data roles
- Always complete messages - call
complete_messageafter processing to remove from queue - Use topics for fan-out - when multiple consumers need the same messages, use topics with subscriptions
- This crate is pre-production - APIs may change; pin your dependency version with cargo commands in your dependency workflow
Reference Links
Limitations
- Use this skill only when the task clearly matches its upstream source and local project context.
- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.