Unrecoverable error: amqp:not-allowed - connection is closing. Operation 'begin' cannot be performed.

[benlings]

Bug Report

• import path of package in question: "github.com/Azure/azure-sdk-for-go/sdk/messaging/azservicebus"

• SDK version: v1.8.1

• output of go version: go version go1.26.1

• What happened?

Periodically (every few months), we see the following error in one of our services.

Error{Condition: amqp:not-allowed, Description: The AMQP object in-connection656105([SERVER NAME REDACTED]) is closing. Operation 'begin' cannot be performed., Info: map[]}

We get this error in both our receive loop and when sending a message. The receive loop seems to recover on the next iteration of the loop. Sending doesn't recover - we don't see any successful sends from the service instance until it's restarted.

• What did you expect or want to happen?

SDK either shouldn't error in this situation or should successfully recover/retry.

• How can we reproduce it?

Unfortunately, we've not been able to reliably reproduce.

• Anything we should know about your environment.

This is a microservice running in Kubernetes (AKS). Container image has debian:12 as a base image. Each service opens a single connection (azservicebus.NewClientFromConnectionString), then one Sender per topic/queue and one Receiver per topic subscription/queue. These all have a lifetime of the whole service process.

[github-actions]

Thank you for your feedback. Tagging and routing to the team member(s) best able to assist.

//cc: @EldertGrootenboer @skarri-microsoft @j7nw4r @SwayGom @sagar0207

[github-actions]

🎯 Agentic Issue Triage

Summary: The azservicebus SDK intermittently enters an unrecoverable state when an AMQP connection is closing, surfacing an amqp:not-allowed error that prevents a Sender from successfully sending messages until the service process is restarted.

📋 Issue Details

Module: github.com/Azure/azure-sdk-for-go/sdk/messaging/azservicebus
Affected API: Client, Sender, Receiver
Scenarios:

• A Sender receives amqp:not-allowed error when the underlying AMQP connection is closing and never auto-recovers — subsequent sends fail indefinitely
• A Receiver sees the same error but recovers on the next iteration of its receive loop

Root ask: The SDK should either not surface this error to the caller or automatically recover/retry when the AMQP connection is closing, bringing the Sender back to a healthy state without requiring a process restart.

🔎 Debugging / Reproduction Notes

The error amqp:not-allowed: The AMQP object in-connection... is closing. Operation 'begin' cannot be performed. indicates the connection received a remote close frame while a new AMQP session (begin) was being opened. This is a transient broker-side event but the Go SDK's Sender does not reconnect.

Suggested investigation steps:

1. Check whether Sender.SendMessage (and internal link re-attach logic) handles the amqp:not-allowed error condition and whether it should trigger a reconnect/retry cycle similar to how Receiver handles it.
2. Review whether the connection-level close propagates a sentinel error that distinguishes "connection is shutting down" from other amqp:not-allowed errors, and ensure the retry policy handles it.
3. Test with a long-lived connection in an AKS environment and simulate a broker-side connection close (e.g., namespace failover, idle timeout) to trigger the condition reliably.

🏷️ Label Confidence

• Category: Client — the issue is in sdk/messaging/azservicebus, which is a data-plane client library (not under sdk/resourcemanager/).
• Service: Service Bus — explicitly identified by the import path sdk/messaging/azservicebus.
• Confidence: High — the module path uniquely identifies both the category and service with no ambiguity.

👥 Owner Routing

• Matched CODEOWNERS entry: # ServiceLabel: %Service Bus (line 117) — single-label match on Service Bus.
• AzureSdkOwners: none listed for this entry.
• ServiceOwners: @EldertGrootenboer, @skarri-microsoft, @j7nw4r, @SwayGom, @sagar0207.
• Routing action: Added Service Attention and needs-team-attention labels; issue left unassigned per Service Attention routing path. ServiceOwners mentioned via routing comment.
• Scan notes: Scanned CODEOWNERS bottom-to-top; the first matching # ServiceLabel: %Service Bus entry (line 117) was the only such entry in the file. No AzureSdkOwners were present for this entry.

Warning

⚠️ Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• releaseassets.githubusercontent.com

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "releaseassets.githubusercontent.com"

See Network Configuration for more information.

Generated by Agentic Triage for issue #27016 · ● 509.2K · ◷