Skip to content

Service Bus WebSocket connection breaks after 15 seconds #44028

@shivani-0705

Description

@shivani-0705
  • Package Name: azure-servicebus
  • Package Version: 17.14.2
  • Python Version: 3.13

Describe the bug
We’re encountering an issue with the Azure Service Bus SDK for Python when using AMQP over WebSocket. The connection consistently breaks after 15 seconds. - azure.servicebus.aio._base_handler_async | AMQP error occurred: (AMQPConnectionError('Error condition: ErrorCondition.SocketError\n Error Description: Can not send frame out due to exception: Cannot write to closing transport')), condition: (<ErrorCondition.SocketError: b'amqp:socket-error'>), description: ('Can not send frame out due to exception: Cannot write to closing transport').

To Reproduce
Steps to reproduce the behavior:

  1. `import asyncio
    import logging
    import logging.config
    import os

from azure.servicebus import TransportType
from azure.servicebus.aio import AutoLockRenewer, ServiceBusClient

logging.config.dictConfig(
{
"version": 1,
"disable_existing_loggers": False,
"root": {
"level": "NOTSET",
"handlers": ["console", "file"],
},
"handlers": {
"console": {
"formatter": "simple",
"level": "INFO",
"class": "logging.StreamHandler",
"stream": "ext://sys.stdout",
},
"file": {
"formatter": "detailed",
"level": "DEBUG",
"class": "logging.FileHandler",
"filename": "sb.log",
"mode": "w",
},
},
"formatters": {
"simple": {"format": "%(levelname)-8s | %(name)s | %(message)s"},
"detailed": {
"format": "[%(asctime)s][%(levelname)-8s][%(name)s] %(message)s"
},
},
}
)
logging.captureWarnings(True)
logger = logging.getLogger("main")

connstr = os.environ["SERVICE_BUS_CONNECTION_STR"]
queue_name = os.environ["SERVICE_BUS_QUEUE_NAME"]

async def main() -> None:
# CHANGE ME
transport_type = TransportType.AmqpOverWebsocket
async with ServiceBusClient.from_connection_string(
conn_str=connstr,
transport_type=transport_type,
) as sb_client:
receiver = sb_client.get_queue_receiver(queue_name=queue_name)
renewer = AutoLockRenewer()
async with receiver, renewer:
# CHANGE ME
counter = 14
while True:
messages = await receiver.receive_messages(max_message_count=1)
logger.info(f"Received {len(messages)} messages")
if not messages:
break

            for msg in messages:
                renewer.register(receiver, msg)
                sleep_duration = float(counter)
                logger.info(
                    f"Handling message {counter}: sleeping for {sleep_duration} ..."
                )
                await asyncio.sleep(sleep_duration)
                logger.info(f"Handling message {counter} DONE")
                await receiver.complete_message(msg)
                counter += 1

asyncio.run(main())`

Errors start happening right after the 15 second mark:

INFO | main | Received 1 messages INFO | main | Handling message 14: sleeping for 14.0 ... INFO | main | Handling message 14 DONE INFO | main | Received 1 messages INFO | main | Handling message 15: sleeping for 15.0 ... INFO | main | Handling message 15 DONE INFO | main | Received 1 messages INFO | main | Handling message 16: sleeping for 16.0 ... INFO | main | Handling message 16 DONE INFO | azure.servicebus.aio._base_handler_async | AMQP error occurred: (AMQPConnectionError('Error condition: ErrorCondition.SocketError\n Error Description: Can not send frame out due to exception: Cannot write to closing transport')), condition: (<ErrorCondition.SocketError: b'amqp:socket-error'>), description: ('Can not send frame out due to exception: Cannot write to closing transport').

This behavior is discussed in Issue #31067 - #31067

Expected behavior
The WebSocket connection remains stable beyond 15 seconds without requiring custom renewal logic

Heartbeats sent by the underlying transport are acknowledged automatically by the SDK, so the connection does not close prematurely.

Users should be able to:

Receive a message.

Wait or process for longer than 15 seconds.

Complete or settle the message successfully without the connection breaking.

The SDK should handle connection keep‑alive internally, ensuring reliability for workloads that involve longer processing times.

This contrasts with the actual behavior you’re seeing, where the connection drops after 15 seconds unless you manually trigger activity (like lock renewal).

Screenshots

Image

Metadata

Metadata

Assignees

No one assigned

    Labels

    Service AttentionWorkflow: This issue is responsible by Azure service team.Service Buscustomer-reportedIssues that are reported by GitHub users external to the Azure organization.needs-team-attentionWorkflow: This issue needs attention from Azure service team or SDK teamquestionThe issue doesn't require a change to the product in order to be resolved. Most issues start as that

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions