[BUG] SDK does not throw an error when connecting to Azure Service Bus if ports 5671 and 5672 are blocked

[muskaan62]

Describe the bug
When outbound ports 5671 and 5672 are blocked, the SDK does not report any connection failure while attempting to connect to Azure Service Bus. Instead of failing with an exception, the connection attempt appears to succeed or remains unaffected, even though network access through the blocked ports should prevent connectivity.

Exception or Stack Trace
No exception or stack trace is generated.

To Reproduce

• Configure the application to connect to an Azure Service Bus namespace using the SDK.
• Block outbound traffic on ports 5671 and 5672 using firewall rules or network policies.
• Run the application and create a Service Bus client.
• Attempt to establish a connection or perform a send/receive operation.

public static void main(String[] args) {
        IterableStream<ServiceBusReceivedMessage> receivedMessages;
        CONNECTION_STRING = "Endpoint=sb://*****.servicebus.windows.net/;SharedAccessKeyName=****;SharedAccessKey=****";
        try {
            // Scenario 1: Auto-acknowledge with message limit
            ServiceBusClientBuilder clientBuilder = new ServiceBusClientBuilder()
                    .connectionString(CONNECTION_STRING);

            receiver = clientBuilder
                    .receiver()
                    .maxAutoLockRenewDuration(Duration.ofSeconds(5))
                    .queueName(QUEUE_NAME)
                    .disableAutoComplete()
                    .receiveMode(ServiceBusReceiveMode.PEEK_LOCK)
                    .prefetchCount(0)
                    .buildClient();
            receivedMessages = BigInteger.valueOf(5) == null
                    ? receiver.receiveMessages(1)
                    : receiver.receiveMessages(1, Duration.ofSeconds(5));
            receivedMessages.stream().forEach(m -> {
                System.out.println("\n[PROCESS] Message:");
                System.out.println("  ID: " + m.getMessageId());
                System.out.println("  Sequence: " + m.getSequenceNumber());
                System.out.println("  Subject: " + m.getSubject());
                System.out.println("  Content: " +  m.getBody().toString());
                System.out.println("  Delivery Count: " + m.getDeliveryCount());
                receiver.complete(m);
                System.out.println("acknowledged message: " + m.getMessageId());

            });
            receiver.close();

        } catch (Exception e) {
            System.err.println("[ERROR] " + e.getMessage());
            e.printStackTrace();
            receiver.close();
        }
        System.out.println("\n" + "=".repeat(80));
        System.out.println("Simulation completed!");
    }

Expected behavior

The SDK should detect that the required network ports are unavailable and fail the connection or operation with an appropriate network-related exception.

Actual behavior

No exception is thrown. The SDK does not report a connection failure even though ports 5071 and 5072 are blocked.
Screenshots

Setup (please complete the following information):

• OS: linux ubuntu
• IDE: IntelliJ
• Library/Libraries: com.azure:azure-messaging-servicebus:7.17.13
• Java version: 11
• App Server/Environment: standalone

If you suspect a dependency version mismatch (e.g. you see NoClassDefFoundError, NoSuchMethodError or similar), please check out Troubleshoot dependency version conflict article first. If it doesn't provide solution for the problem, please provide:

• verbose dependency tree (mvn dependency:tree -Dverbose)
• exception message, full stack trace, and any available logs

Additional context
Add any other context about the problem here.

Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

• Bug Description Added
• Repro Steps Added
• Setup information Added

[github-actions]

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

//cc: @EldertGrootenboer @skarri-microsoft

[github-actions]

🎯 Agentic Issue Triage

Summary: When outbound ports 5071 and 5072 are blocked, the azure-messaging-servicebus SDK does not throw an exception or report a connection failure, leaving the application unaware that connectivity to Azure Service Bus is unavailable.

📋 Issue Details

Package: com.azure:azure-messaging-servicebus:7.17.13
Affected API: ServiceBusClientBuilder, ServiceBusReceiverClient.receiveMessages()
Scenarios:

• Firewall/network policy blocks outbound ports 5071 and 5072 (AMQP ports used by Service Bus)
• SDK builds client and calls receiveMessages() without throwing a connection error or timeout exception

Root ask: The SDK should surface a meaningful network/connection exception when required ports are unavailable, rather than silently failing or hanging.

🔎 Debugging / Reproduction Notes

The Service Bus SDK uses AMQP over ports 5671 (AMQPS) and 5672, or 5671/443 via WebSocket; ports 5071/5072 may be the non-TLS AMQP variants. When those ports are blocked, the underlying Reactor-Netty/AMQP connection attempt may time out without propagating the error up to the user-facing receiveMessages() call.

Suggested investigation steps:

1. Enable SDK logging (AZURE_LOG_LEVEL=verbose) to see whether the AMQP transport layer logs a connection failure internally.
2. Verify which transport mode (AMQP vs. AMQP-over-WebSocket) is in use; if WebSocket fallback is available via port 443, that may mask the port block.
3. Check whether receiveMessages(int, Duration) eventually returns an empty iterable vs. blocking indefinitely — the timeout duration may be swallowing the error.
4. Review the ServiceBusClientBuilder transport type setting and test with AmqpTransportType.AMQP explicitly set to isolate the port behavior.
5. Confirm SDK version — 7.17.13 vs. latest (7.17.19) — to determine if a fix was already released.

🏷️ Label Confidence

• Category: Client — Issue concerns SDK client behavior (missing exception propagation), not a REST API or service-side defect.
• Service: Service Bus — Explicitly names com.azure:azure-messaging-servicebus and Azure Service Bus namespace.
• Confidence: High — Package and service are explicitly named in the issue body; category is unambiguous.

👥 Owner Routing

• Matched CODEOWNERS entry: # ServiceLabel: %Service Bus (line 465) — issue labels include "Service Bus"; this is the first match during bottom-to-top scan.
• AzureSdkOwners: none listed for this entry
• ServiceOwners: @EldertGrootenboer @skarri-microsoft
• Routing action: Added "Service Attention" and "needs-team-attention" labels; @mentioned ServiceOwners via routing comment.
• Scan notes: %Service Bus %Track 1 entry (line 469) was encountered first but not matched because the issue does not have the "Track 1" label. %Service Bus catch-all matched next.

Generated by Agentic Triage for #49802 · 27.8 AIC · ⌖ 5.61 AIC · ⊞ 11K · ◷

[EldertGrootenboer]

You're correct that no exception is thrown, and that is the expected behavior here rather than a silent failure.

When outbound access to port 5671 is blocked, the client treats it as a transient connection problem and keeps retrying the connection in the background.
A time-bounded receive such as receiveMessages(1, Duration.ofSeconds(5)) returns an empty result once its wait window elapses, so the call completes without an exception.
Retrying instead of failing is intentional, because it lets the client reconnect on its own once connectivity returns, without your application having to recreate the client.

We are not planning to change this, for two reasons.
Making the receive call throw on a connection problem would be a breaking change for applications that depend on this automatic recovery during temporary network interruptions.
A blocked port and a brief network outage also look identical at connection time (both appear as a connection timeout), so the SDK cannot reliably tell "the port is blocked" apart from "the network is momentarily unavailable."

To catch a persistent connectivity problem, monitor it from your application.
A few options:

• A watchdog that alerts when no messages arrive for longer than you expect.
• A separate connectivity or health check against the namespace endpoint.
• SDK logs, which show the repeated reconnect attempts while the port is blocked (enable via AZURE_LOG_LEVEL or your SLF4J configuration).

Service Bus uses 5671 for AMQP over TLS and 443 for AMQP over WebSockets, and does not use 5672.
If 5671 is blocked but 443 is open, you can switch the client to AMQP over WebSockets using the transport type setting.