Send, receive, and manage Azure Queue Storage messages in Rust

Client library guidance for Azure Queue Storage in Rust via the official azure_storage_queue crate - sending, receiving, and managing queue messages, using RBAC-based authentication. It explicitly warns to use only the official crate published by the azure-sdk crates.io user, since official crates use underscores in their names and none carry version 0.21.0, never an unofficial or community crate. Installation:

cargo add azure_storage_queue azure_identity azure_core tokio

with a note that a direct azure_core dependency is only needed if the code imports azure_core types directly, since azure_storage_queue's re-exports cover most usage; the account endpoint is configured via a required AZURE_STORAGE_QUEUE_ENDPOINT environment variable. Authentication uses DeveloperToolsCredential for local development and ManagedIdentityCredential for production, explicitly noting Rust has no single DefaultAzureCredential type unlike other Azure SDKs. It documents two client types: QueueServiceClient for account-level operations and listing queues, and QueueClient, derived from the service client via queue_client("<name>"), for per-queue send, receive, and delete operations. It walks through the core workflow with full runnable code for sending a message via QueueMessage/send_message, receiving messages and reading message_text from the response, deleting a received message using its message ID and pop receipt, and peeking at messages without removing them. It maps four RBAC roles to the access they grant: Storage Queue Data Reader for read and peek, Storage Queue Data Contributor for read/write, Storage Queue Data Message Sender for send only, and Storage Queue Data Message Processor for receive and delete. Eight best practices cover using cargo add/cargo remove instead of hand-editing Cargo.toml, adding azure_core only when its types are imported directly, the dev-vs-production credential split, never hardcoding credentials, assigning the correct RBAC role per identity, using QueueServiceClient as the entry point, always deleting messages after processing with their message ID and pop receipt, and reusing thread-safe clients across tasks rather than recreating them.

Use it when a Rust application needs to send or receive messages from Azure Queue Storage, create or manage queues, peek, receive, or delete queue messages, or needs RBAC-based auth for queue operations.

Input is a queue operation request - send, receive, peek, delete, or manage a queue - plus the storage account endpoint. Output is Rust code using the official crate, for example sending a message:

let message = QueueMessage {
    message_text: Some("hello world".to_string()),
};
queue_client.send_message(message.try_into()?, None).await?;

Built on the official azure_storage_queue crate plus azure_identity (DeveloperToolsCredential, ManagedIdentityCredential), azure_core, and tokio; documents Entra ID RBAC role assignment and links to the crate's docs.rs reference, crates.io page, and GitHub source.

Rust developers integrating Azure Queue Storage messaging into an application who need the correct official crate, credential setup, and RBAC roles rather than a community alternative.