Fix service bus client lifecycle

[James Chapman (JC-wk)]

resolves #4977

What is being addressed

inconsistent ServiceBusClient lifecycle management in deployment_status_updater.py, airlock_request_status_update.py, and runner.py.
key message listeners repeatedly instantiate ServiceBusClient inside infinite loops but discard the instances without calling close() or wrapping them in context managers. This can leak connection sockets and AMQP channels under transient reconnect loops.

How is this addressed

• Prevents connection socket leaks: ServiceBusClient instances are now properly closed using async context managers
  Prevents AMQP channel leaks: Ensures channels are cleaned up even under transient reconnect scenarios
  Consistent pattern: All three files now follow the same best practice of using
• Update CHANGELOG.md
• Increment version

[github-actions]

Unit Test Results

724 tests   724 ✅  11s ⏱️
  1 suites    0 💤
  1 files      0 ❌

Results for commit a9d15ee.

♻️ This comment has been updated with latest results.

[Copilot]

Pull request overview

This PR fixes inconsistent Azure Service Bus client lifecycle handling across the API service-bus listeners and the resource processor runner to reduce the risk of leaking sockets/AMQP channels during long-running polling and reconnect loops.

Changes:

• Wrap ServiceBusClient usage in async context managers so clients are deterministically closed.
• Add backoff (asyncio.sleep(10)) on connection/unknown exceptions in the runner and service-bus listeners.
• Update runner unit tests to account for the async context manager usage; add a changelog entry.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
api_app/service_bus/deployment_status_updater.py	Uses async with ServiceBusClient(...) to ensure the client is closed across reconnect cycles.
api_app/service_bus/airlock_request_status_update.py	Uses async with ServiceBusClient(...) to ensure the client is closed; adjusts retry sleeps.
resource_processor/vmss_porter/runner.py	Uses async with ServiceBusClient(...) for proper client teardown; adds retry sleeps on exceptions.
resource_processor/tests_rp/test_runner.py	Updates mocks to handle the ServiceBusClient async context manager behavior.
CHANGELOG.md	Adds an unreleased BUG FIXES entry for the lifecycle fix.

[Jack Morris (rudolphjacksonm)]

/test-extended

[github-actions]

🤖 pr-bot 🤖

🏃 Running extended tests: https://github.com/microsoft/AzureTRE/actions/runs/28157965154 (with refid 93594175)

(in response to this comment from Jack Morris (@rudolphjacksonm))

[maxmartin-cgi]

/test-extended

[github-actions]

🤖 pr-bot 🤖

🏃 Running extended tests: https://github.com/microsoft/AzureTRE/actions/runs/28224500075 (with refid 93594175)

(in response to this comment from maxmartin-cgi)

[maxmartin-cgi]

/test-extended

[github-actions]

🤖 pr-bot 🤖

🏃 Running extended tests: https://github.com/microsoft/AzureTRE/actions/runs/28243761740 (with refid 93594175)

(in response to this comment from maxmartin-cgi)

[maxmartin-cgi]

/test-extended

[github-actions]

🤖 pr-bot 🤖

⚠️ Cannot run tests as PR is not mergeable. Ensure that the PR is open and doesn't have any conflicts.

(in response to this comment from maxmartin-cgi)

[Marcus Robinson (marrobi)]

From Opus 4.8

---

I found one correctness issue and one behavior risk:

• In api_app/service_bus/airlock_request_status_update.py, ServiceBusClient is now created once outside the inner polling loop and reused forever. That means if the connection drops or the client becomes unhealthy after a transient failure, the code can keep retrying with the same stale client instead of recreating it. The previous pattern re-established the client each iteration; this change may reduce leaks, but it also makes recovery less robust. Consider moving the async with ServiceBusClient(...) back inside the retry loop, or explicitly recreating the client after connection-related failures.

• In deployment_status_updater.py, the logic still keeps a single ServiceBusClient alive across the inner loop as well. If the intent is just to avoid leaks, that’s fine, but the current structure can hold the client open indefinitely while also suppressing reconnect churn. Make sure this is intentional and that there’s a clean exit/recreate path when the receiver or client encounters a fatal state.

• resource_processor/vmss_porter/runner.py now wraps ServiceBusClient in async with, but the exception handlers only sleep and continue. If receive_message() ever exits due to a non-fatal error, the outer async with will close the client and then immediately reopen it on the next runner() invocation, which is fine. Just verify the tests cover the __aenter__/__aexit__ path for the new context-manager usage.

• The changelog entry mentions all three files, but the behavioral change in airlock_request_status_update.py is materially different from the others: it changes reconnection semantics, not just lifecycle management. That should be called out more explicitly in the PR description or handled with a narrower refactor.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

[Marcus Robinson (marrobi)]

James Chapman (@JC-wk) thoughts on:

deployment_status_updater.py gained an elaborate structure: an inner while True loop, an hourly client-recreation timer, and a nested try/except OperationTimeoutError. The other two files were not given equivalent treatment — they simply wrap the client and rely on the outer loop. The PR description promises a "consistent pattern," but the deployment updater now diverges significantly. Either simplify the deployment updater to match, or document why the session-based (NEXT_AVAILABLE_SESSION) consumer needs special handling.

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated no new comments.

Suppressed comments (1)

CHANGELOG.md:18

• This changelog entry links to PR #4930, but the PR description/issue context indicates this fix resolves #4977. Using the wrong reference makes the entry hard to trace and contradicts the stated “resolves #4977” intent.

* Fix inconsistent ServiceBusClient lifecycle management in deployment_status_updater.py, airlock_request_status_update.py, and runner.py to prevent connection socket and AMQP channel leaks ([#4930](https://github.com/microsoft/AzureTRE/pull/4930))

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated no new comments.

Suppressed comments (1)

CHANGELOG.md:20

• This changelog entry references PR #4930, but the PR description/issue context for this change says it resolves #4977. Using the wrong link makes the changelog hard to trace back to the actual work item.

* Fix inconsistent ServiceBusClient lifecycle management in deployment_status_updater.py, airlock_request_status_update.py, and runner.py to prevent connection socket and AMQP channel leaks ([#4930](https://github.com/microsoft/AzureTRE/pull/4930))

[Chris Chapman (ChrisChapman-gh)]

Assuming the conflicts are resolved and the tests pass - looks ok to me.