Fix GrpcChannel handle leak in AzureManaged backend #625

torosent · 2026-01-27T01:40:19Z

Summary

What changed?

Added inline channel caching in ConfigureGrpcChannel class using ConcurrentDictionary<string, Lazy<GrpcChannel>>
Made ConfigureGrpcChannel implement IDisposable to properly dispose channels when the ServiceProvider is disposed
Channels are cached per configuration key (options name + endpoint + task hub)

Why is this change needed?

When the Durable Task Scheduler service is unreachable, the IConfigureNamedOptions<DurableTaskSchedulerOptions>.Configure() method was being called multiple times (on each retry)
Each call created a new GrpcChannel, which allocates internal HTTP handlers and socket connections
The channels were never disposed because when options.Channel is pre-set (AzureManaged case), GetCallInvoker() returns default for the disposable reference
This caused handle/resource leaks that accumulated over time, especially when the service was unavailable

Issues / work items

Related #N/A (fixes handle leak issue)

Project checklist

Release notes are not required for the next release
- Otherwise: Notes added to release_notes.md
Backport is not required
- Otherwise: Backport tracked by issue/PR #issue_or_pr
All required tests have been added/updated (unit tests, E2E tests)
Breaking change?
- If yes: No breaking changes - internal implementation change only, public API unchanged

AI-assisted code disclosure (required)

Was an AI tool used? (select one)

No
Yes, AI helped write parts of this PR (e.g., GitHub Copilot)
Yes, an AI agent generated most of this PR

If AI was used:

Tool(s): GitHub Copilot (Claude)
AI-assisted areas/files:
- src/Client/AzureManaged/DurableTaskSchedulerClientExtensions.cs (modified)
- src/Worker/AzureManaged/DurableTaskSchedulerWorkerExtensions.cs (modified)
- test/Client/AzureManaged.Tests/DurableTaskSchedulerClientExtensionsTests.cs (modified)
- test/Worker/AzureManaged.Tests/DurableTaskSchedulerWorkerExtensionsTests.cs (modified)
What you changed after AI output: Simplified from separate GrpcChannelCache class to inline ConcurrentDictionary<string, Lazy<GrpcChannel>> per reviewer feedback

AI verification (required if AI was used):

I understand the code and can explain it
I verified referenced APIs/types exist and are correct
I reviewed edge cases/failure paths (timeouts, retries, cancellation, exceptions)
I reviewed concurrency/async behavior
I checked for unintended breaking or behavior changes

Testing

Automated tests

Result: Passed
- test/Client/AzureManaged.Tests - 33 tests passed
- test/Worker/AzureManaged.Tests - 31 tests passed
- test/Shared/AzureManaged.Tests - 20 tests passed
- Total: 84 tests passed

Manual validation (only if runtime/behavior changed)

Not performed (behavior change is internal - channels are now cached and disposed properly)

Notes for reviewers

The ConfigureGrpcChannel class now uses ConcurrentDictionary<string, Lazy<GrpcChannel>> for thread-safe channel caching
Lazy<GrpcChannel> ensures thread-safe initialization without holding locks during channel creation (avoids potential deadlocks)
Channel keys include options name, endpoint, and task hub to ensure proper isolation
Fire-and-forget ShutdownAsync() is called before Dispose() for graceful shutdown of in-flight RPCs
The volatile keyword on the disposed field ensures proper memory visibility when checking disposal state from multiple threads

- Add GrpcChannelCache for thread-safe channel caching by endpoint - Update Client/Worker extensions to use shared cache - Ensure channels are disposed when ServiceProvider disposes - Add comprehensive unit and integration tests

test/Shared/AzureManaged.Tests/GrpcChannelCacheTests.cs

src/Shared/AzureManaged/GrpcChannelCache.cs

cgillum · 2026-01-27T01:53:14Z

I asked Copilot CLI to review this with the following prompt since the currently proposed solution looks far more complicated than I was expecting.

Please review this PR. I'm especially interested in knowing if a significantly simpler solution is possible

Here's what the response was:

   PR Review Summary

   Overall Assessment: The fix correctly addresses the GrpcChannel leak, but there's a significantly simpler solution available.

   The Core Problem

   When options.Channel is pre-set (AzureManaged case), GetCallInvoker() returns default for the disposable reference (line 549 in
   GrpcDurableTaskClient.cs), meaning the channel is never disposed. Combined with IConfigureNamedOptions.Configure() being called on each
   retry, this creates a resource leak.

   Simpler Alternative

   Instead of introducing a full GrpcChannelCache class with locking, disposal tracking, and 400+ lines of test code, consider this much
   simpler fix:

   Option 1: Make the channel a Lazy<GrpcChannel> in the options class

     // In ConfigureGrpcChannel class
     class ConfigureGrpcChannel(IOptionsMonitor<DurableTaskSchedulerClientOptions> schedulerOptions) :
         IConfigureNamedOptions<GrpcDurableTaskClientOptions>
     {
         readonly ConcurrentDictionary<string, Lazy<GrpcChannel>> channels = new();

         public void Configure(string? name, GrpcDurableTaskClientOptions options)
         {
             string key = name ?? Options.DefaultName;
             DurableTaskSchedulerClientOptions source = schedulerOptions.Get(key);

             options.Channel = this.channels.GetOrAdd(
                 $"{key}:{source.EndpointAddress}:{source.TaskHubName}",
                 _ => new Lazy<GrpcChannel>(source.CreateChannel)).Value;
         }
     }

   This is ~10 lines vs 170+ lines for GrpcChannelCache, and the IConfigureOptions<T> is already registered as a singleton, so the channel
   cache lives in that singleton's state.

   Option 2: Cache directly on the scheduler options instance

   Since DurableTaskSchedulerClientOptions instances are already managed via the options system, add a lazily-created channel property there:

     // In DurableTaskSchedulerClientOptions
     Lazy<GrpcChannel>? cachedChannel;

     internal GrpcChannel GetOrCreateChannel()
     {
         this.cachedChannel ??= new Lazy<GrpcChannel>(this.CreateChannel);
         return this.cachedChannel.Value;
     }

   Concerns with Current Implementation

     - Unused methods: Replace() and TryRemove() in GrpcChannelCache are never called - they add complexity without value.
     - Fire-and-forget disposal: The DisposeChannelAsync pattern with _ = Task.Run(...) can orphan disposal if the app terminates quickly.
   Consider whether synchronous disposal is acceptable.
     - Over-engineering: The cache handles scenarios (explicit replacement, removal) that don't apply to this use case.
     - Code quality issues already flagged: Nested if statements, unused variable, generic catch clause.

   Recommendation

   Go with the simpler ConcurrentDictionary<string, Lazy<GrpcChannel>> approach directly in the ConfigureGrpcChannel class. This:

     - Fixes the leak
     - Requires no new classes
     - Has minimal test surface area
     - Is easier to understand and maintain

   If you need disposal support, implement IDisposable on ConfigureGrpcChannel and register it properly with DI (though the existing code
   doesn't dispose channels either, so this may be acceptable).

I can try to review this more deeply tomorrow.

- Move channel factory call outside lock to prevent deadlock - Combine nested if statements in Replace method - Use 'using' statement for channel disposal - Catch Exception instead of bare catch - Remove unused variable in test

src/Shared/AzureManaged/GrpcChannelCache.cs

- Remove separate GrpcChannelCache class - Inline channel caching directly in ConfigureGrpcChannel using ConcurrentDictionary<string, Lazy<GrpcChannel>> - Make ConfigureGrpcChannel implement IDisposable for proper channel disposal - Remove unused Replace() and TryRemove() methods - Add disposal verification tests - Reduces complexity from 170+ LOC to ~40 LOC per extension

src/Client/AzureManaged/DurableTaskSchedulerClientExtensions.cs

src/Worker/AzureManaged/DurableTaskSchedulerWorkerExtensions.cs

src/Client/AzureManaged/DurableTaskSchedulerClientExtensions.cs

src/Worker/AzureManaged/DurableTaskSchedulerWorkerExtensions.cs

- Use LINQ Where() instead of if inside foreach for filtering channels - Narrow catch (Exception) to specific types (OperationCanceledException, ObjectDisposedException)

test/Client/AzureManaged.Tests/DurableTaskSchedulerClientExtensionsTests.cs

src/Worker/AzureManaged/DurableTaskSchedulerWorkerExtensions.cs

…ception handling

src/Client/AzureManaged/DurableTaskSchedulerClientExtensions.cs

src/Worker/AzureManaged/DurableTaskSchedulerWorkerExtensions.cs

Copilot

Pull request overview

Fixes a gRPC channel/handle leak in the AzureManaged Durable Task Scheduler integration by caching GrpcChannel instances and disposing them when the DI container is disposed.

Changes:

Cache GrpcChannel instances inside ConfigureGrpcChannel using ConcurrentDictionary<..., Lazy<GrpcChannel>>.
Make the channel configurators disposable so cached channels are cleaned up on ServiceProvider disposal.
Add tests intended to validate channel reuse and disposal behavior for both client and worker extensions.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 12 comments.

File	Description
src/Client/AzureManaged/DurableTaskSchedulerClientExtensions.cs	Adds per-configuration `GrpcChannel` caching and async disposal logic for client-side options configuration.
src/Worker/AzureManaged/DurableTaskSchedulerWorkerExtensions.cs	Adds per-configuration `GrpcChannel` caching and async disposal logic for worker-side options configuration.
test/Client/AzureManaged.Tests/DurableTaskSchedulerClientExtensionsTests.cs	Adds tests for channel reuse/isolation and disposal on DI container teardown for client extensions.
test/Worker/AzureManaged.Tests/DurableTaskSchedulerWorkerExtensionsTests.cs	Adds tests for channel reuse/isolation and disposal on DI container teardown for worker extensions.

Copilot · 2026-01-27T22:58:12Z

src/Worker/AzureManaged/DurableTaskSchedulerWorkerExtensions.cs

+    sealed class ConfigureGrpcChannel : IConfigureNamedOptions<GrpcDurableTaskWorkerOptions>, IAsyncDisposable
    {
+        readonly IOptionsMonitor<DurableTaskSchedulerWorkerOptions> schedulerOptions;
+        readonly ConcurrentDictionary<string, Lazy<GrpcChannel>> channels = new();
+        int disposed;


PR description mentions IDisposable and a volatile disposed flag, but this implementation is IAsyncDisposable-only and the disposed field isn’t volatile (and is read without Volatile.Read). Either update the PR description or adjust the implementation to match (e.g., implement IDisposable and use volatile/Volatile.Read for the disposed check).

Copilot · 2026-01-27T22:58:12Z

src/Client/AzureManaged/DurableTaskSchedulerClientExtensions.cs

+    sealed class ConfigureGrpcChannel : IConfigureNamedOptions<GrpcDurableTaskClientOptions>, IAsyncDisposable
    {
+        readonly IOptionsMonitor<DurableTaskSchedulerClientOptions> schedulerOptions;
+        readonly ConcurrentDictionary<string, Lazy<GrpcChannel>> channels = new();
+        int disposed;


PR description mentions IDisposable and a volatile disposed flag, but this implementation is IAsyncDisposable-only and the disposed field isn’t volatile (and is read without Volatile.Read). Either update the PR description or adjust the implementation to match (e.g., implement IDisposable and use volatile/Volatile.Read for the disposed check).

test/Client/AzureManaged.Tests/DurableTaskSchedulerClientExtensionsTests.cs

test/Worker/AzureManaged.Tests/DurableTaskSchedulerWorkerExtensionsTests.cs

Copilot · 2026-01-27T22:58:13Z

src/Client/AzureManaged/DurableTaskSchedulerClientExtensions.cs

+            if (exceptions is { Count: > 0 })
+            {
+                throw new AggregateException(exceptions);
+            }


DisposeAsync throws an AggregateException when any channel shutdown/dispose fails. Throwing from ServiceProvider disposal can surface as app shutdown failures and is difficult for callers to handle. Consider making this best-effort (swallow/log disposal errors) instead of throwing.

Copilot · 2026-01-27T22:58:14Z

test/Client/AzureManaged.Tests/DurableTaskSchedulerClientExtensionsTests.cs

+        // Act - configure two different named clients with different endpoints
+        mockBuilder1.Object.UseDurableTaskScheduler("endpoint1.westus3.durabletask.io", ValidTaskHub, credential);
+        mockBuilder2.Object.UseDurableTaskScheduler("endpoint2.westus3.durabletask.io", ValidTaskHub, credential);
+        ServiceProvider provider = services.BuildServiceProvider();
+


This test uses different endpoints for different named options, so it will pass even if the cache key accidentally ignores the options name. To validate name isolation in the cache key, use the same endpoint/task hub for both names and assert the channels differ; also dispose the ServiceProvider to avoid leaking channels.

src/Worker/AzureManaged/DurableTaskSchedulerWorkerExtensions.cs

Copilot · 2026-01-27T22:58:14Z

src/Worker/AzureManaged/DurableTaskSchedulerWorkerExtensions.cs

+            string optionsName = name ?? Options.DefaultName;
+            DurableTaskSchedulerWorkerOptions source = this.schedulerOptions.Get(optionsName);
+
+            // Create a cache key based on the options name, endpoint, and task hub.
+            // This ensures channels are reused for the same configuration


CreateChannel() behavior depends on more than endpoint/task hub (e.g., ResourceId, Credential, AllowInsecureCredentials, and WorkerId via the call credentials interceptor). If any of these values change while EndpointAddress/TaskHubName stay the same (e.g., via options reload), the cached channel will be reused with stale settings. Consider including these fields in the cache key or enforcing immutability for them.

@copilot open a new pull request to apply changes based on this feedback

Copilot · 2026-01-27T22:58:14Z

src/Worker/AzureManaged/DurableTaskSchedulerWorkerExtensions.cs

+            if (exceptions is { Count: > 0 })
+            {
+                throw new AggregateException(exceptions);
+            }


DisposeAsync throws an AggregateException when any channel shutdown/dispose fails. Throwing from ServiceProvider disposal can surface as app shutdown failures and is difficult for callers to handle. Consider making this best-effort (swallow/log disposal errors) instead of throwing.

…sionsTests.cs Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

…sionsTests.cs Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Copilot · 2026-01-28T15:39:22Z

@torosent I've opened a new pull request, #626, to work on those changes. Once the pull request is ready, I'll request review from you.

src/Worker/AzureManaged/DurableTaskSchedulerWorkerExtensions.cs

Copilot

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 6 comments.

Copilot · 2026-01-28T15:42:43Z

src/Worker/AzureManaged/DurableTaskSchedulerWorkerExtensions.cs

+            // Create a cache key based on the options name, endpoint, and task hub.
+            // This ensures channels are reused for the same configuration
+            // but separate channels are created for different configurations.
+            // Use a delimiter character (\u001F) that will not appear in typical endpoint URIs.
+            string cacheKey = $"{optionsName}\u001F{source.EndpointAddress}\u001F{source.TaskHubName}";


The cache key uses source.EndpointAddress, but DurableTaskSchedulerWorkerOptions.CreateChannel() normalizes endpoints by adding a scheme when missing. As a result, equivalent endpoints (with vs without https://) will not share a cache entry and will create multiple channels. Consider normalizing the endpoint string for the cache key the same way CreateChannel() does (or use the channel target/normalized endpoint).

Copilot · 2026-01-28T15:42:43Z

test/Worker/AzureManaged.Tests/DurableTaskSchedulerWorkerExtensionsTests.cs

+        mockBuilder.Object.UseDurableTaskScheduler(ValidEndpoint, ValidTaskHub, credential);
+        using ServiceProvider provider = services.BuildServiceProvider();
+


The ServiceProvider created here is not disposed. Since these tests now create/dispose cached gRPC channels via DI, the provider should be wrapped in using/await using to avoid leaking resources across test runs.

@copilot open a new pull request to apply changes based on this feedback

Copilot · 2026-01-28T15:42:44Z

test/Worker/AzureManaged.Tests/DurableTaskSchedulerWorkerExtensionsTests.cs

+        mockBuilder2.Object.UseDurableTaskScheduler("endpoint.westus3.durabletask.io", ValidTaskHub, credential);
+        using ServiceProvider provider = services.BuildServiceProvider();
+


The ServiceProvider created here is not disposed. Please wrap it in using/await using so the container can dispose the cached channels and other tracked disposables, preventing cross-test resource leakage.

Copilot · 2026-01-28T15:42:44Z

src/Client/AzureManaged/DurableTaskSchedulerClientExtensions.cs

+#if NET7_0_OR_GREATER
+            ObjectDisposedException.ThrowIf(this.disposed == 1, this);
+#else
+            if (this.disposed == 1)
+            {


disposed is written via Interlocked.Exchange in DisposeAsync, but read here via a plain field read. For cross-thread visibility, the read should use Volatile.Read(ref this.disposed) (or make the field volatile) to ensure Configure reliably observes disposal under concurrency.

Copilot · 2026-01-28T15:42:44Z

src/Worker/AzureManaged/DurableTaskSchedulerWorkerExtensions.cs

+            ObjectDisposedException.ThrowIf(this.disposed == 1, this);
+#else
+            if (this.disposed == 1)
+            {
+                throw new ObjectDisposedException(nameof(ConfigureGrpcChannel));


disposed is written via Interlocked.Exchange in DisposeAsync, but read here via a plain field read. Use Volatile.Read(ref this.disposed) (or make the field volatile) so concurrent calls to Configure reliably observe disposal.

Copilot · 2026-01-28T15:42:45Z

test/Worker/AzureManaged.Tests/DurableTaskSchedulerWorkerExtensionsTests.cs

+        // Resolve options multiple times to trigger channel configuration via new options instances
+        IOptionsFactory<GrpcDurableTaskWorkerOptions> optionsFactory = provider.GetRequiredService<IOptionsFactory<GrpcDurableTaskWorkerOptions>>();
+        GrpcDurableTaskWorkerOptions options1 = optionsFactory.Create(Options.DefaultName);
+        GrpcDurableTaskWorkerOptions options2 = optionsFactory.Create(Options.DefaultName);
+


This test uses IOptionsMonitor.Get twice for the same name, which typically returns the same cached options instance. As a result, it may pass even if ConfigureGrpcChannel.Configure creates a new channel on each invocation. To actually validate channel reuse across multiple configurations, consider using IOptionsFactory<GrpcDurableTaskWorkerOptions>.Create(...) twice (like the client tests do).

#626)

src/Client/AzureManaged/DurableTaskSchedulerClientExtensions.cs

+                catch (Exception ex)
+                {
+                    exceptions ??= new List<Exception>();
+                    exceptions.Add(ex);
+                }


src/Worker/AzureManaged/DurableTaskSchedulerWorkerExtensions.cs

Co-authored-by: Copilot Autofix powered by AI <223894421+github-code-quality[bot]@users.noreply.github.com>

Copilot · 2026-01-28T16:18:45Z

@torosent I've opened a new pull request, #627, to work on those changes. Once the pull request is ready, I'll request review from you.

Copilot

Pull request overview

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

Copilot · 2026-01-28T16:22:56Z

src/Client/AzureManaged/DurableTaskSchedulerClientExtensions.cs

+            string credentialType = source.Credential?.GetType().FullName ?? "null";
+            string retryOptionsKey = source.RetryOptions != null
+                ? $"{source.RetryOptions.MaxRetries}|{source.RetryOptions.InitialBackoffMs}|{source.RetryOptions.MaxBackoffMs}|{source.RetryOptions.BackoffMultiplier}|{(source.RetryOptions.RetryableStatusCodes != null ? string.Join(",", source.RetryOptions.RetryableStatusCodes) : string.Empty)}"
+                : "null";
+            string cacheKey = $"{optionsName}\u001F{source.EndpointAddress}\u001F{source.TaskHubName}\u001F{source.ResourceId}\u001F{credentialType}\u001F{source.AllowInsecureCredentials}\u001F{retryOptionsKey}";
+            options.Channel = this.channels.GetOrAdd(


The cache key only includes the credential type (FullName), but CreateChannel() captures and uses the TokenCredential instance (e.g., for AccessTokenCache and auth headers). If the credential instance changes while keeping the same type (e.g., two ManagedIdentityCredential instances with different client IDs, or config reload), this will incorrectly reuse a channel created with the old credential. Consider keying on the credential instance identity (or a stable credential-specific identifier) rather than only its type, and also normalize EndpointAddress the same way CreateChannel() does (scheme/no-scheme) to avoid duplicate channels for the same effective endpoint.

Copilot · 2026-01-28T16:22:56Z

src/Client/AzureManaged/DurableTaskSchedulerClientExtensions.cs

    {
+        readonly IOptionsMonitor<DurableTaskSchedulerClientOptions> schedulerOptions;
+        readonly ConcurrentDictionary<string, Lazy<GrpcChannel>> channels = new();
+        int disposed;


disposed is used as a cross-thread flag (read in Configure, written via Interlocked.Exchange in DisposeAsync) but is read without volatile/Volatile.Read. Also, Configure can race with DisposeAsync (an in-flight Configure can create/add a channel after DisposeAsync has enumerated/cleared the dictionary), which would leak the channel. Consider synchronizing Configure vs DisposeAsync (e.g., a lock/reader-writer gate) and using volatile/Volatile.Read for the flag.

Suggested change

int disposed;

volatile int disposed;

Copilot · 2026-01-28T16:22:57Z

src/Worker/AzureManaged/DurableTaskSchedulerWorkerExtensions.cs

+            string credentialType = source.Credential?.GetType().FullName ?? "null";
+            string cacheKey = $"{optionsName}\u001F{source.EndpointAddress}\u001F{source.TaskHubName}\u001F{source.ResourceId}\u001F{credentialType}\u001F{source.AllowInsecureCredentials}\u001F{source.WorkerId}";
+            options.Channel = this.channels.GetOrAdd(
+                cacheKey,


The cache key only includes the credential type (FullName), but CreateChannel() uses the TokenCredential instance (token cache + auth headers). If the credential instance changes while keeping the same type, this will incorrectly reuse a channel created with the old credential. Consider keying on the credential instance identity (or a stable credential-specific identifier) rather than only its type, and normalize EndpointAddress the same way CreateChannel() does to avoid duplicate channels for equivalent endpoints.

Copilot · 2026-01-28T16:22:57Z

src/Worker/AzureManaged/DurableTaskSchedulerWorkerExtensions.cs

    {
+        readonly IOptionsMonitor<DurableTaskSchedulerWorkerOptions> schedulerOptions;
+        readonly ConcurrentDictionary<string, Lazy<GrpcChannel>> channels = new();
+        int disposed;


disposed is used as a cross-thread flag (read in Configure, written via Interlocked.Exchange in DisposeAsync) but is read without volatile/Volatile.Read. Also, Configure can race with DisposeAsync (an in-flight Configure can create/add a channel after DisposeAsync has enumerated/cleared the dictionary), which would leak the channel. Consider synchronizing Configure vs DisposeAsync (e.g., a lock/reader-writer gate) and using volatile/Volatile.Read for the flag.

Suggested change

int disposed;

volatile int disposed;

torosent · 2026-01-28T16:48:19Z

@copilot open a new pull request to apply changes based on the comments in this thread

Copilot · 2026-01-28T16:48:34Z

@torosent I've opened a new pull request, #628, to work on those changes. Once the pull request is ready, I'll request review from you.

torosent · 2026-01-28T18:10:02Z

Closing this PR and will open a new fixed PR

Fix GrpcChannel handle leak in AzureManaged backend

882ea20

- Add GrpcChannelCache for thread-safe channel caching by endpoint - Update Client/Worker extensions to use shared cache - Ensure channels are disposed when ServiceProvider disposes - Add comprehensive unit and integration tests

github-code-quality bot found potential problems Jan 27, 2026

View reviewed changes

Address PR review comments and fix potential deadlock

387c960

- Move channel factory call outside lock to prevent deadlock - Combine nested if statements in Replace method - Use 'using' statement for channel disposal - Catch Exception instead of bare catch - Remove unused variable in test

github-code-quality bot found potential problems Jan 27, 2026

View reviewed changes

src/Shared/AzureManaged/GrpcChannelCache.cs Fixed Show fixed Hide fixed

github-code-quality bot found potential problems Jan 27, 2026

View reviewed changes

Address remaining CodeQL comments

19f521f

- Use LINQ Where() instead of if inside foreach for filtering channels - Narrow catch (Exception) to specific types (OperationCanceledException, ObjectDisposedException)

cgillum reviewed Jan 27, 2026

View reviewed changes

Refactor gRPC channel disposal to use IAsyncDisposable and improve ex…

9b67032

…ception handling

torosent marked this pull request as ready for review January 27, 2026 22:49

Copilot AI review requested due to automatic review settings January 27, 2026 22:49

github-code-quality bot found potential problems Jan 27, 2026

View reviewed changes

src/Client/AzureManaged/DurableTaskSchedulerClientExtensions.cs Fixed Show fixed Hide fixed

src/Worker/AzureManaged/DurableTaskSchedulerWorkerExtensions.cs Fixed Show fixed Hide fixed

Copilot started reviewing on behalf of torosent January 27, 2026 22:49 View session

Copilot AI reviewed Jan 27, 2026

View reviewed changes

Update test/Client/AzureManaged.Tests/DurableTaskSchedulerClientExten…

f307902

…sionsTests.cs Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Copilot AI review requested due to automatic review settings January 28, 2026 15:36

Update src/Worker/AzureManaged/DurableTaskSchedulerWorkerExtensions.cs

95bc2d0

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Copilot started reviewing on behalf of torosent January 28, 2026 15:37 View session

torosent and others added 2 commits January 28, 2026 07:37

Update test/Worker/AzureManaged.Tests/DurableTaskSchedulerWorkerExten…

a585f2c

…sionsTests.cs Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Update test/Worker/AzureManaged.Tests/DurableTaskSchedulerWorkerExten…

b6630f2

…sionsTests.cs Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Copilot AI mentioned this pull request Jan 28, 2026

Fix gRPC channel cache key to include all channel-affecting properties #626

Merged

github-code-quality bot found potential problems Jan 28, 2026

View reviewed changes

src/Worker/AzureManaged/DurableTaskSchedulerWorkerExtensions.cs Fixed Show fixed Hide fixed

Copilot AI reviewed Jan 28, 2026

View reviewed changes

Fix gRPC channel cache key to include all channel-affecting properties (

5ec4cd9

#626)

github-code-quality bot found potential problems Jan 28, 2026

View reviewed changes

src/Client/AzureManaged/DurableTaskSchedulerClientExtensions.cs

Comment on lines +176 to +180

catch (Exception ex)

{

exceptions ??= new List<Exception>();

exceptions.Add(ex);

}

src/Worker/AzureManaged/DurableTaskSchedulerWorkerExtensions.cs Fixed Show fixed Hide fixed

Potential fix for pull request finding 'Generic catch clause'

609df5d

Co-authored-by: Copilot Autofix powered by AI <223894421+github-code-quality[bot]@users.noreply.github.com>

Copilot AI review requested due to automatic review settings January 28, 2026 16:17

Copilot started reviewing on behalf of torosent January 28, 2026 16:17 View session

Copilot AI mentioned this pull request Jan 28, 2026

Fix resource leaks in DurableTaskSchedulerWorkerExtensionsTests #627

Merged

Copilot AI reviewed Jan 28, 2026

View reviewed changes

Fix resource leaks in DurableTaskSchedulerWorkerExtensionsTests (#627)

d5d1151

Copilot AI mentioned this pull request Jan 28, 2026

Fix race condition and credential caching in GrpcChannel lifecycle #628

Merged

Initial plan (#628)

9a005e5

torosent closed this Jan 28, 2026

nytian mentioned this pull request Jan 28, 2026

Fix GrpcChannel handle leak in AzureManaged backend #629

Merged

		mockBuilder.Object.UseDurableTaskScheduler(ValidEndpoint, ValidTaskHub, credential);
		using ServiceProvider provider = services.BuildServiceProvider();

		mockBuilder2.Object.UseDurableTaskScheduler("endpoint.westus3.durabletask.io", ValidTaskHub, credential);
		using ServiceProvider provider = services.BuildServiceProvider();

Fix GrpcChannel handle leak in AzureManaged backend #625

Fix GrpcChannel handle leak in AzureManaged backend #625

Uh oh!

Conversation

torosent commented Jan 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

What changed?

Why is this change needed?

Issues / work items

Project checklist

AI-assisted code disclosure (required)

Was an AI tool used? (select one)

Testing

Automated tests

Manual validation (only if runtime/behavior changed)

Notes for reviewers

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cgillum commented Jan 27, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Jan 27, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 27, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI Jan 27, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 27, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Copilot AI Jan 27, 2026

Choose a reason for hiding this comment

Uh oh!

torosent Jan 28, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 27, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI commented Jan 28, 2026

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Jan 28, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 28, 2026

Choose a reason for hiding this comment

Uh oh!

torosent Jan 28, 2026

Choose a reason for hiding this comment

Uh oh!

torosent commented Jan 27, 2026 •

edited

Loading