fix: reuse Azure and Oracle clients across requests; document DI lifetime audit - #71
Merged
Merged
Conversation
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Repository: simplify9/coderabbit/.coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…time audit Prompted by the S3 client-lifetime incident fixed in 8.1.11, audited the other network-backed providers for the same class of bug (building a fresh SDK client on every DI resolution instead of reusing a pooled, thread-safe one): - Azure (SW.CloudFiles.AS): same AddTransient bug as S3 had, and worse — the DI extension registered a singleton BlobContainerClient that was never actually used, since CloudFilesService's constructor built its own client instead of taking one as a parameter. In the non-managed- identity auth path that means a synchronous, blocking GetBlobContainers list call on every single construction. Fixed: CloudFilesService now takes BlobContainerClient via constructor injection (reusing the registered singleton), and ICloudFilesService is now AddSingleton. - Oracle (SW.CloudFiles.OC): was AddScoped, so a fresh ObjectStorageClient + UploadManager (and a disk read of the PEM/config file) were built once per HTTP request rather than once per resolution. Changed to AddSingleton so the client is built once for the process lifetime. - Google Cloud (SW.CloudFiles.GC): already correct — ICloudFilesService is AddScoped, but the actual StorageClient/UrlSigner are AddSingleton and injected, so no repeated client construction. No change needed. No known consumer currently uses Azure/GCS/Oracle (only S3 is actively used today), so this is library-quality debt rather than a live incident, unlike the S3 fix. Documented the full audit in CLAUDE.md and added the client-reuse/timeout notes to README.md. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
mmalkhatib
force-pushed
the
muhannad/fix-as-oc-client-lifetime
branch
from
August 25, 2026 13:58
4521b9e to
75737e4
Compare
AhmadRAbuhussein
approved these changes
Aug 25, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up to #70 (S3 client-lifetime fix, live prod incident). Audited the other three network-backed providers for the same class of bug — building a fresh SDK client on every DI resolution instead of reusing a pooled, thread-safe one.
SW.CloudFiles.AS): sameAddTransientbug as S3, and worse. The DI extension registered a singletonBlobContainerClientthat was never actually used —CloudFilesService's constructor built its own client via a field initializer instead of taking one as a parameter. In the non-managed-identity auth path, that means a synchronous, blockingGetBlobContainers()list call on every single construction, not just a fresh handshake. Fixed:CloudFilesServicenow takesBlobContainerClientvia constructor injection (reusing the registered singleton),ICloudFilesServiceis nowAddSingleton.SW.CloudFiles.OC): wasAddScoped— milder than Transient, but still built a freshObjectStorageClient+UploadManager(plus a disk read of the PEM/config file) once per HTTP request. Changed toAddSingleton.SW.CloudFiles.GC): already correct —ICloudFilesServiceisAddScoped, but the realStorageClient/UrlSignerareAddSingletonand injected, so no repeated client construction regardless. No change.Also documents the full audit in
CLAUDE.mdand adds client-reuse/timeout notes toREADME.md.None of Azure/GCS/Oracle are used by any Traxis service today (only S3 is) — this is library-quality debt, not a live incident.
Test plan
dotnet buildclean across the whole solutionSW.CloudFiles.AS.UnitTest/SW.CloudFiles.OC.UnitTestfail identically with and without this change (confirmed by reverting and re-running) — pre-existing, need live cloud credentials, consistent with CI'srun-tests: 'false'🤖 Generated with Claude Code