[ServiceBus] aio client and receiver annotate `auto_lock_renewer` with the sync `AutoLockRenewer` class, contradicting their own docstrings

[SirPangolin]

• Package Name: azure-servicebus
• Package Version: 7.14.3
• Operating System: Windows 11 Pro (10.0.26200)
• Python Version: 3.13.5

Describe the bug
The async client's receiver factory methods type the auto_lock_renewer keyword with the synchronous AutoLockRenewer, while their own docstrings - and the working runtime behavior - call for azure.servicebus.aio.AutoLockRenewer

Static type checkers therefore reject the documented, runtime-correct usage, forcing a cast() / suppression comment at every call site. Note the annotation doesn't merely disagree with the docs - it names the class that cannot work there: the sync renewer's renewal loop is thread-based and would invoke the async receiver's coroutine methods without awaiting them.

To Reproduce
Steps to reproduce the behavior:

1. Type-check the following with pyright (or mypy/ty):

from azure.servicebus.aio import AutoLockRenewer, ServiceBusClient

  async def main() -> None:
      client = ServiceBusClient.from_connection_string("...")
      renewer = AutoLockRenewer()
      receiver = client.get_subscription_receiver(
          "topic",
          "subscription",
          auto_lock_renewer=renewer,
      )

2. Pyright 1.1.411 reports:

Argument of type "AutoLockRenewer" cannot be assigned to parameter "auto_lock_renewer"
  of type "AutoLockRenewer | None" in function "get_subscription_receiver"
    "azure.servicebus.aio._async_auto_lock_renewer.AutoLockRenewer" is not assignable to
    "azure.servicebus._common.auto_lock_renewer.AutoLockRenewer"

(ty 0.x reports the equivalent invalid-argument-type.)

Expected behavior
The aio module's annotations reference azure.servicebus.aio.AutoLockRenewer, matching the docstrings, so the documented usage type-checks without suppressions.

Screenshots
N/A - diags quoted above.

Additional context
Runtime behavior confirms the docstring, not the annotation: passing the aio AutoLockRenewer through this parameter against a live namespace works correctly (verified with a 30s-lock subscription and a 40s handler hold - the renewer fired on schedule, locked_until_utc advanced past the original expiry, and complete_message settled the message). The annotation appears to be a copy of the sync client's signature; the sync module (azure/servicebus/_servicebus_client.py) uses the same import legitimately.

[github-actions]

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

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

[github-actions]

🎯 Agentic Issue Triage

Summary: The async azure-servicebus client's receiver factory methods (e.g., get_subscription_receiver) incorrectly annotate the auto_lock_renewer parameter with the synchronous AutoLockRenewer class instead of azure.servicebus.aio.AutoLockRenewer, causing static type checkers to reject the documented, runtime-correct usage.

📋 Issue Details

Package: azure-servicebus 7.14.3
Affected API: ServiceBusClient.get_subscription_receiver() (and likely all async receiver factory methods such as get_queue_receiver())
Scenarios:

• Passing azure.servicebus.aio.AutoLockRenewer to auto_lock_renewer in async receiver factory methods raises a type error with pyright (and mypy/ty), because the annotation references the sync AutoLockRenewer
• The runtime behaves correctly — the async renewer fires on schedule — but every call site requires a cast() or suppression comment to satisfy the type checker

Root ask: Update the auto_lock_renewer parameter annotation in the async client module to reference azure.servicebus.aio.AutoLockRenewer, matching the docstrings and runtime behavior.

🔎 Debugging / Reproduction Notes

The async client (azure/servicebus/aio/_servicebus_client.py) appears to reuse the synchronous ServiceBusClient import for AutoLockRenewer — a copy-paste from azure/servicebus/_servicebus_client.py where that import is legitimate. The fix is to update the async module's annotation (and/or overload) to import azure.servicebus.aio._async_auto_lock_renewer.AutoLockRenewer instead.

Suggested investigation steps:

1. Locate all auto_lock_renewer parameter annotations in sdk/servicebus/azure-servicebus/azure/servicebus/aio/ and confirm they reference the sync class
2. Update the import and type annotation in the async client module(s) to use azure.servicebus.aio.AutoLockRenewer
3. Run pyright/mypy against the sample snippet from the issue to verify the fix resolves the type error without breaking the sync path

🏷️ Label Confidence

• Category: Client — the issue is a type annotation defect in the data-plane async client library (azure-servicebus), not a management-plane library
• Service: Service Bus — package is azure-servicebus under /sdk/servicebus/
• Confidence: High — the package name, SDK path, and issue content unambiguously identify a single service and data-plane category

👥 Owner Routing

• Matched CODEOWNERS entry: # ServiceLabel: %Service Bus (line 743) — direct match on predicted service label "Service Bus"
• AzureSdkOwners: none listed
• ServiceOwners: @EldertGrootenboer, @skarri-microsoft, @j7nw4r
• Routing action: Added "Service Attention" and "needs-team-attention" labels; left unassigned; @mentioned ServiceOwners via routing comment
• Scan notes: Scanning bottom-to-top, line 743 was the first (and only) # ServiceLabel: %Service Bus entry; no AzureSdkOwners block was present for this entry

Generated by Agentic Triage for issue #47948 · 35.9 AIC · ⌖ 11.4 AIC · ⊞ 9.5K · ◷