[service-bus] Unhandled OperationTimeoutError rejections from unguarded receiver.close() calls

[kglstoris]

• Package Name: @azure/service-bus
• Package Version: 7.10.0-beta.4
• Operating system:
• nodejs
  • version: Node 24
• browser
  • name/version:
• typescript
  • version: 5.9.3
• Is the bug related to documentation in
  • README.md
  • source code documentation
  • SDK API docs on https://learn.microsoft.com

Describe the bug
We are still seeing unhandled promise rejections from OperationTimeoutError when an AMQP session close times out causing application crashes. Similar to #35342, the calling code is wrapped in try/catch and the issue seems to be with the library.

OperationTimeoutError: Unable to close the amqp session local-1_remote-1_connection-2 due to operation timeout.
  at Timeout.actionAfterTimeout (/usr/src/app/node_modules/.pnpm/rhea-promise@3.0.3/node_modules/rhea-promise/dist/lib/session.js:175:32)
  at listOnTimeout (node:internal/timers:605:17)
  at process.processTimers (node:internal/timers:541:7)

The fix for #35342 added a try/catch around several receiver.close() calls, but it looks like two call sites were potentially missed in:

• core/receiverHelper.ts's await receiver?.close();
• core/batchingReceiver.ts's await.receiver.close()

To Reproduce
N/A. We are unable to consistently reproduce the issue

Additional context
Also encountered the issue in version 7.9.5 of @azure/service-bus

[github-actions]

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

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

[github-actions]

🎯 Agentic Issue Triage

Summary: Unhandled OperationTimeoutError promise rejections from two receiver.close() call sites in @azure/service-bus that were missed by the fix for #35342, causing application crashes even when user code is wrapped in try/catch.

📋 Issue Details

Package: @azure/service-bus v7.10.0-beta.4 (also confirmed in v7.9.5)
Affected API: receiver.close() in core/receiverHelper.ts (line 135) and core/batchingReceiver.ts (line 377)
Scenarios:

• Application crashes with unhandled OperationTimeoutError during AMQP session close under network/timeout conditions
• User code is wrapped in try/catch but the rejection escapes because the await is unguarded inside the library

Root ask: Wrap the two missed receiver.close() / receiver?.close() call sites in try/catch to prevent unhandled promise rejections, mirroring the fix applied for #35342.

🔎 Debugging / Reproduction Notes

The stack trace originates in rhea-promise's session close timeout handler, which fires outside the caller's try/catch scope. The issue author has identified two specific call sites:

1. sdk/servicebus/service-bus/src/core/receiverHelper.ts line 135 — await receiver?.close(); (unguarded)
2. sdk/servicebus/service-bus/src/core/batchingReceiver.ts line 377 — await receiver.close() (unguarded)

Suggested investigation steps:

1. Compare the call sites above against the guarded close() calls introduced by the fix for Dangling promise causes uncaughtexception in @azure/service-bus #35342 to confirm the omission.
2. Wrap both call sites in try/catch (logging or swallowing OperationTimeoutError) consistent with the existing pattern.
3. Audit remaining receiver.close(), sender.close(), and session.close() call sites for similar unguarded awaits.

🏷️ Label Confidence

• Category: Client — issue is about the @azure/service-bus data-plane client SDK behavior, not management or engineering systems.
• Service: Service Bus — explicitly named package @azure/service-bus; confirmed by reference issue Dangling promise causes uncaughtexception in @azure/service-bus #35342 which carries Client + Service Bus labels.
• Confidence: High — package and service are unambiguous; pattern matches quality reference issue Dangling promise causes uncaughtexception in @azure/service-bus #35342 (has customer-reported, issue-addressed, Client, Service Bus).

👥 Owner Routing

• Matched CODEOWNERS entry: # ServiceLabel: %Service Bus (line 289) — only label required is "Service Bus", which is present.
• AzureSdkOwners: none listed
• ServiceOwners: @EldertGrootenboer @j7nw4r @SwayGom @sagar0207 @skarri-microsoft
• Routing action: Added Service Attention and needs-team-attention labels; left unassigned; @mentioned ServiceOwners via routing comment.
• Scan notes: No multi-label entries for "Service Bus" + "Service Attention" or similar were found in the file; line 289 was the only matching entry.

Generated by Agentic Triage for #39348 · 35.4 AIC · ⌖ 5.66 AIC · ⊞ 10.3K · ◷