[ServiceBus] aio AutoLockRenewer never prunes completed futures from _futures, leaking memory over a long-running consumer

[SirPangolin]

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

Describe the bug
azure.servicebus.aio.AutoLockRenewer grows its internal _futures list by one entry on every register(...) and does not release those entries as the corresponding messages are settled - the list is only drained when the renewer is closed. A long-running consumer using the documented one-renewer-per-app pattern therefore accumulates one entry per message processed for the whole lifetime of the renewer: unbounded memory growth, reclaimed only on close().

This is the pattern the docs recommend (one long-lived renewer, register each message in the receive loop), so idiomatic usage hits it:

lock_renewal = AutoLockRenewer()
async with servicebus_receiver:
    async for message in servicebus_receiver:
        lock_renewal.register(servicebus_receiver, message, max_lock_renewal_duration=60)
        await process_message(message)
        await servicebus_receiver.complete_message(message)   # renewal completes here...
        # ...but its Future stays in lock_renewal._futures forever

To Reproduce

1. Create a single long-lived AutoLockRenewer().
2. Receive from a queue holding a few hundred messages; for each message, register(receiver, msg, ...) then settle it immediately with complete_message(msg) (so no renewal stays active).
3. Print len(renewer._futures) periodically.
4. Observe it climb to the all-time processed count and never shrink, even though every registered renewal has already completed; process RSS grows in lockstep. Only await renewer.close() releases them.

Expected behavior
A completed renewal's Future should be dropped from _futures when it finishes, so the list stays bounded by the number of active (unsettled) renewals rather than the process's all-time message count. In the repro above len(_futures) should hover near 0 (each message settles immediately), not grow to processed.

Screenshots
Not applicable

Additional context
The growth is proportional to the total number of messages handled over the process's uptime, not to how many renewals are active at once - the accumulated entries are only released when the renewer itself is closed, so a single app-lifetime renewer (the documented pattern) that stays open until shutdown holds them for the whole run. Higher throughput or longer uptime makes it more pronounced; a short-lived script that closes the renewer promptly won't notice.

[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: AutoLockRenewer in azure-servicebus (aio) never removes completed renewal Future entries from its internal _futures list after messages are settled, causing unbounded memory growth proportional to the total messages processed over the renewer's lifetime.

📋 Issue Details

Package: azure-servicebus 7.14.3
Affected API: azure.servicebus.aio.AutoLockRenewer._futures / AutoLockRenewer.register()
Scenarios:

• Long-lived renewer (recommended pattern) processing many messages accumulates one Future entry per message, never pruned until close() is called
• Process RSS grows linearly with messages processed, not with active renewals

Root ask: Completed renewal Futures should be removed from _futures once they finish, keeping the list bounded by active (in-flight) renewals only.

🔎 Debugging / Reproduction Notes

The leak is straightforward to verify: create a single AutoLockRenewer(), process hundreds of messages with register() + immediate complete_message(), and observe len(renewer._futures) growing monotonically.

Suggested investigation steps:

1. Locate AutoLockRenewer.register() in sdk/servicebus/azure-servicebus/azure/servicebus/_common/auto_lock_renewer.py and inspect how Futures are appended to _futures.
2. Check whether a .add_done_callback() or equivalent mechanism is in place to prune completed Futures — the report indicates there is none.
3. Add a done_callback on each renewal Future that removes it from _futures upon completion (use a lock or thread-safe structure if needed for the async path).
4. Verify the fix with the reproduction script in the issue: len(renewer._futures) should remain near 0 after each complete_message().

🏷️ Label Confidence

• Category: Client — azure-servicebus is a data-plane client library (not azure-mgmt-servicebus)
• Service: Service Bus — explicitly named package and title; matched to /sdk/servicebus/ path
• Confidence: High — package, service, and category are unambiguous

👥 Owner Routing

• Matched CODEOWNERS entry: # ServiceLabel: %Service Bus (line 746) — service label matches exactly
• AzureSdkOwners: none listed
• ServiceOwners: @EldertGrootenboer @skarri-microsoft @j7nw4r
• Routing action: Added Service Attention and needs-team-attention; @mentioned ServiceOwners via routing comment
• Scan notes: Bottom-to-top scan passed %Web Apps (line 740) — did not match; stopped at %Service Bus (line 746)

Generated by Agentic Triage for issue #48366 · 25.5 AIC · ⌖ 7.17 AIC · ⊞ 9.6K · ◷