[Host.AzureServiceBus] Keep the session enabled subscription with AutoDeleteOnIdle alive

[zarusz]

Azure Service Bus will delete session enabled subscriptions when AutoDeleteOnIdle is set and when there was no message traffic.
However, for non-session enabled subsciption it will not drop the subscription.

Explore an feature for SMB to be able to keep the session enabled subscription alive (or re-create it on demand).

---

You’ve bumped into how AutoDeleteOnIdle actually works on Service Bus: it watches for activity on the entity itself — not whether there are active TCP connections/consumers.

What counts as “activity” (resets the idle timer)

Per Microsoft’s docs, a subscription is considered active only when there are receives, updates to the subscription, new rules added, or peek/browse operations. If none of those happen for the configured interval, the subscription is deleted. The docs phrase it as: “The interval is reset when a message is added to or removed from the subscription” and detail idleness criteria in a table. ([Microsoft Learn]1)

Why session-enabled behaves differently

With non-session subscriptions, many client SDKs continuously issue receive (long-poll) operations even when there are no messages; those receive attempts count as activity and keep resetting the idle timer. (Historically, Microsoft has clarified that even empty receives/management ops reset the timer.) ([GitHub]2)

With session-enabled subscriptions, the client typically calls AcceptNextSession/AcceptSession. If there are no sessions with messages, the broker doesn’t deliver anything and the client isn’t actually performing successful receive operations against the subscription. In other words: you can have “active consumers” (open connections, waiting on a session) yet no entity-level activity, so the subscription idles out and is auto-deleted. This aligns with the idleness rules above. ([Microsoft Learn]3)

Ways to prevent deletion (pick one)

• Disable or increase AutoDeleteOnIdle for that subscription (e.g., “Never auto-delete” in the portal). Safest if the entity should be long-lived. ([Stack Overflow]4)

• Generate periodic activity on the subscription:

  • Send a tiny “heartbeat” message to a known session (e.g., maintenance-session) at an interval shorter than your idle window; your consumer can immediately complete it. This causes a receive and resets the timer. ([Microsoft Learn]1)
  • Run a lightweight peek (browse) or a trivial management update (e.g., flip metadata or upsert a no-op rule) on a schedule; these also count as activity. ([Microsoft Learn]3)

• Auto-forward the subscription to some holding queue (auto-forwarding is treated like a receiver and prevents idleness), if that fits your topology. ([Microsoft Learn]3)

Quick sanity checks

• Verify there isn’t another process deleting the subscription (rare, but worth confirming). ([Stack Overflow]5)
• Ensure you’re not on a configuration that limits AutoDeleteOnIdle (e.g., specific partitioning scenarios historically had caveats). ([Stack Overflow]6)