Azure Service Bus for Rust
Guides Rust developers in sending and receiving Azure Service Bus messages through queues, topics, and subscriptions.
The document requires the official crate, discourages hardcoded credentials, and provides DeveloperToolsCredential/ManagedIdentityCredential guidance plus scoped RBAC roles. However, sending, receiving, and completing messages create external state changes without explicit user confirmation, and it omits data-flow disclosure, sensitive-data handling, idempotency, rollback, and recovery guidance, so points are deducted.
Installation, authentication, queue/topic/subscription, and settlement flows are internally consistent, and examples propagate errors with Result. However, the crate is explicitly early-stage, with no guidance for retries, lock expiry, dead-lettering, connection failures, or abnormal inputs, and no skill-specific test evidence is supplied; the static score is therefore limited.
Triggers, Rust audience, and queue/topic/subscription scenarios are reasonably clear. Non-fit ranges, API/version boundaries, input/output contracts, and environment requirements are not defined, and Chinese-language support is absent. The core function depends on network access to Azure Service Bus, whose mainland-China reachability is not established by the supplied material, so points are deducted.
The document has clear sections for installation, environment variables, authentication, workflows, RBAC, practices, references, MIT licensing, and author metadata. It lacks concrete version-pinning examples, changelog, maintenance ownership and update path, troubleshooting, and fuller limitations; the scope of the instruction not to edit Cargo.toml is also unexplained.
The material covers the core send, receive, topic, and subscription tasks and offers directly useful starting snippets. However, the crate is explicitly unsuitable for production, while the examples omit complete configuration, lifecycle management, retries, and production reliability handling. Static evidence does not establish compilation or complete outcomes, so the score remains within the static ceiling.
The skill supplies docs.rs, crates.io, and Azure SDK source references, with repository-level CI/test material providing limited corroboration. The supplied evidence does not show skill-specific tests, build results, or independent reproduction, and nothing was executed in this review, so a higher score is not justified.
- The crate is explicitly in early development and should not be used directly in production; verify and pin the actual version and API before adoption.
- Sending, completing, and abandoning messages change external state; add confirmation boundaries, idempotency, retries, lock renewal, dead-letter, audit, and recovery policies before deployment.
- Do not log message bodies or credentials, and verify Azure Service Bus reachability in the target network environment.
What does this skill do, and when should you use it?
This skill is for Rust applications that use Azure Service Bus for enterprise messaging. It covers installation, identity-based authentication, queue and topic workflows, subscription receivers, and message settlement. It recommends the official azure_messaging_servicebus crate and explains the relevant Entra ID roles. The crate is in early development and should not be used in production because its APIs may change.
Shows how to install azure_messaging_servicebus, azure_identity, and tokio with cargo add; configure SERVICEBUS_NAMESPACE; create a ServiceBusClient with DeveloperToolsCredential or ManagedIdentityCredential; create senders and receivers for queues, topics, and subscriptions; send messages; receive batches; inspect message bodies; complete successfully processed messages; abandon messages for retry; and assign Service Bus Data Sender, Data Receiver, or Data Owner roles.
- A Rust application needs to send work items to an Azure Service Bus queue and uses a sender to publish Message values.
- A Rust worker needs to receive several queue messages, process them, and complete them to prevent redelivery.
- Several consumers need the same published messages, so the application uses a topic with subscriptions for fan-out delivery.
- A developer needs local Azure authentication with DeveloperToolsCredential, while a production design would use ManagedIdentityCredential instead.
What are this skill's strengths and limitations?
- Covers queues, topics, subscriptions, sending, receiving, and settlement semantics.
- Uses the official crate and documents authentication, RBAC, and credential-handling practices.
- Includes copyable asynchronous Rust examples.
- Distinguishes local development credentials from production managed identity.
- The azure_messaging_servicebus crate is explicitly early-development software and should not be used in production.
- APIs may change, and the source provides no stability guarantee or compatibility matrix.
- The source does not show a dedicated test suite or platform-coverage evidence for this skill.
- Azure resources, network access, and appropriate permissions are required; pricing is not documented.
How do you install this skill?
Run npx skills add microsoft/skills and select this skill in the installation wizard for the target agent. Alternatively, clone the collection and copy .github/plugins/azure-sdk-rust/skills/azure-servicebus-rust/ into the target agent skills directory. Add project dependencies with: cargo add azure_messaging_servicebus azure_identity tokio. Add azure_core only if the project directly imports azure_core types.
How do you use this skill?
Use a trigger such as "service bus rust", "ServiceBusClient rust", "send message servicebus rust", "receive message servicebus rust", "queue rust messaging", or "topic subscription rust". Provide the Service Bus namespace and the relevant queue, topic, or subscription, then request a send, receive, or subscription workflow. Set SERVICEBUS_NAMESPACE=<namespace>.servicebus.windows.net and ensure the identity has the required Azure Service Bus data role.