Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[servicebus] Async ServiceBusSender leaks AttributeError ('NoneType' has no attribute 'client_ready_async') after idle timeout, instead of ServiceBusConnectionError

Abierto
#48,921 2 comentarios 1 reacción 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
azure, python

Línea de trabajo

Comienza en la ruta async de ServiceBusSender send_messages y sigue cómo un enlace desconectado por inactividad deja el _handler interno como None. Añade una prueba de regresión para un envío de un solo hilo después de la condición de tiempo de espera por inactividad y verifica que genera ServiceBusConnectionError en lugar de AttributeError o de reconectarse de forma transparente.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Messaging Service Attention Service Bus
Related issues

Same root cause as #35618 and #36334 (internal _handler reset to None),
but a different trigger: those reproduce under concurrent sends and were
closed not_planned with an asyncio.Lock() workaround. This report is a
single-threaded, non-concurrent reproduction driven by Azure's ~10-minute
idle timeout — the lock workaround does not apply.

Describe the bug

A long-lived (singleton) async ServiceBusSender that is reused across sends
works fine until the connection sits idle past Azure's ~10-minute idle timeout.
The next send_messages() raises:

AttributeError: 'NoneType' object has no attribute 'client_ready_async'

Expected: a documented, catchable ServiceBusConnectionError (or transparent
implicit reconnect), so callers can distinguish "stale link, safe to recreate
and retry" from a genuine error (auth/quota/payload).

Because the leaked exception is a bare AttributeError, callers cannot reliably
tell it apart from an ordinary programming bug without string-matching on the
internal attribute name client_ready_async, which is fragile across releases.

Steps to reproduce
  1. Create an async ServiceBusClient, then one ServiceBusSender, and keep both.
  2. await sender.send_messages(...) once — succeeds.
  3. Leave the sender idle for > 10 minutes (Azure idle timeout drops the AMQP link).
  4. await sender.send_messages(...) again.

Result: AttributeError: 'NoneType' object has no attribute 'client_ready_async'
rather than a ServiceBusConnectionError.

Minimal sketch:

import asyncio
from azure.servicebus.aio import ServiceBusClient
from azure.servicebus import ServiceBusMessage

async def main():
    client = ServiceBusClient.from_connection_string(CONN_STR)
    sender = client.get_queue_sender(QUEUE)
    await sender.send_messages(ServiceBusMessage("first"))   # ok
    await asyncio.sleep(11 * 60)                              # exceed idle timeout
    await sender.send_messages(ServiceBusMessage("second"))  # AttributeError

asyncio.run(main())

Expected behavior
The idle-dropped link should surface as ServiceBusConnectionError (the SDK's
documented connection-loss exception), or the sender should reconnect implicitly.
Either way, no internal AttributeError should escape.

Environment
azure-servicebus: 7.14.3 (latest stable)
azure-core: 1.38.2
Python: 3.11.14
OS: Windows 11 (also observed in Linux containers)
Transport: async (azure.servicebus.aio), pure-Python AMQP
Impact / current workaround
We run one persistent sender per worker and must detect this failure to recreate
the sender and retry. Since no typed exception is raised, we string-match:

isinstance(exc, AttributeError) and "client_ready_async" in str(exc)
This is brittle — it depends on an internal attribute name. A typed exception
(or implicit reconnect) would let us delete the string match. Please consider
fixing the idle-timeout path specifically, independently of the concurrency
scenarios in
Azure/azure-sdk-for-python#35618 /
Azure/azure-sdk-for-python#36334.

Lenguaje dominante
Python
Estrellas
5.6k
Forks
3.4k
Merge medio
1 d 18 h
PR fusionados (30 d)
214

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Azure/azure-sdk-for-python

Todos los issues de Azure/azure-sdk-for-python

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.