Azure Queue Storage for Rust
A focused guide for building secure Azure Queue Storage messaging workflows in Rust.
The document restricts users to the official azure_storage_queue crate, recommends RBAC, forbids hardcoded credentials, and distinguishes local from production identity, reducing credential and dependency risk. It does not specify least-privilege networking, user confirmation, sensitive-message handling, data flows, or recovery/rollback for deletion, so points are deducted.
Installation, client construction, send, receive, delete, and peek flows are broadly self-consistent, with errors propagated through Rust Result. The skill provides no skill-specific tests, pinned version, abnormal-input handling, retry/timeout guidance, service-outage diagnostics, or reproducible verification, so the static ceiling and deductions apply.
Triggers, Rust/Azure Queue Storage audience, and primary scenarios are clear, covering send, receive, delete, peek, and RBAC. Non-fit boundaries, queue-creation examples, message-size/encoding limits, Chinese-language use, and mainland-China reachability are not addressed, leaving semantic and environment-fit evidence limited.
The document has metadata, installation, environment variables, authentication, client types, workflows, RBAC, best practices, and references, and declares MIT licensing. It lacks an SDK version or compatibility matrix, changelog, explicit maintenance owner/update path, and troubleshooting; claims of queue creation/management are not backed by examples, so points are deducted.
The examples cover basic client creation, sending, receiving, deleting, and peeking and offer direct value for simple implementations. Placeholders, missing queue-creation/management code, absent production retry and message-constraint guidance, and no execution verification limit completeness and immediate usability.
Crates.io, docs.rs, and Azure SDK source links provide some audit paths, and the code is inspectable. The selected skill has no committed tests or key-path CI execution evidence, so compilation and behavioral correctness cannot be confirmed statically; only limited credit is warranted.
- The examples use storage-account, queue-name, and endpoint placeholders; verify the actual SDK version, API signatures, and RBAC configuration before deployment.
- Message deletion is an irreversible business operation; the document does not explain idempotency, retries, visibility timeouts, dead-lettering, or recovery.
- Do not log message bodies, endpoints, or credentials; the document provides no sensitive-data or logging-governance guidance.
- Mainland-China network reachability and offline alternatives are not documented; Azure service and crates.io access must be validated separately.
What it does & when to use it
This skill helps Rust developers use Azure Queue Storage through Microsoft’s official azure_storage_queue crate. It covers client setup, sending, receiving, deleting, and peeking queue messages, along with Entra ID authentication and RBAC guidance. Examples use DeveloperToolsCredential for local development and ManagedIdentityCredential for production. The repository is an MIT-licensed collection containing 190 separate skills; this profile covers only the Rust queue skill.
Guides installation of azure_storage_queue, azure_identity, azure_core, and tokio; reads AZURE_STORAGE_QUEUE_ENDPOINT; creates a QueueServiceClient and derives a QueueClient; calls send_message, receive_messages, delete_message, and peek_messages; parses queue responses and accesses message text, message IDs, and pop receipts; and maps queue operations to Entra ID RBAC roles.
- A Rust backend developer needs to publish task messages to Azure Queue Storage and wants an official SDK implementation.
- A team is building an asynchronous Rust consumer that must receive and parse queue messages.
- A message-processing service needs to delete messages after successful handling using the message ID and pop receipt.
- An Azure team wants passwordless-style identity handling with separate local-development and production credential guidance.
- A developer needs to inspect queue messages without removing them from the queue.
Pros & cons
- Covers the core queue operations: send, receive, delete, and peek.
- Includes copyable asynchronous Rust examples and an official-crate requirement.
- Explains Entra ID authentication, RBAC roles, and credential-safety practices.
- Clarifies the roles of QueueServiceClient, QueueClient, message IDs, and pop receipts.
- Available through an MIT-licensed skill collection and its documented installation workflow.
- Focused specifically on Azure Queue Storage and Rust; it does not cover other languages or Azure messaging services.
- Requires a real Azure Queue Storage endpoint and configured identity; no offline mock workflow is documented.
- The source does not show an independent test suite or test coverage for this specific Rust skill.
- Storage account, queue name, and endpoint values in the examples are placeholders.
How to install
Install the collection into the selected Agent’s skill directory with npx skills add microsoft/skills, then choose the required skill in the wizard. For manual installation, clone https://github.com/microsoft/skills and copy .github/plugins/azure-sdk-rust/skills/azure-storage-queue-rust/. The README does not specify the exact installation path for this skill on every Agent. Add Rust dependencies with: cargo add azure_storage_queue azure_identity azure_core tokio.
How to use
Give a supporting coding Agent a request such as “Implement Azure Queue Storage message sending, receiving, and deletion in Rust using the official azure_storage_queue crate.” Set AZURE_STORAGE_QUEUE_ENDPOINT=https://<account>.queue.core.windows.net/. Create a QueueServiceClient, derive a QueueClient, use DeveloperToolsCredential locally or ManagedIdentityCredential in production, and assign the identity an appropriate Storage Queue Data RBAC role.
Compared to similar skills
The source explicitly distinguishes the official azure_storage_queue crate from unofficial or community crates and instructs users to use the official one. It does not provide a broader comparison with other queue services or SDKs.