No cache invalidation on options change

[torosent]

gRPC channels are cached per configuration (endpoint, task hub, credential type, etc.). If options are changed after the first channel is created (e.g. via IOptionsMonitor.OnChange or options reload), the cached channel is not updated and will keep using the original configuration until the process restarts or the service provider is disposed.

[github-actions]

Issue Triage

Classification: triage/actionable

Reasoning:
This is a known bug where gRPC channels cached in ConcurrentDictionary in the ConfigureGrpcChannel classes (in both DurableTaskSchedulerClientExtensions.cs and DurableTaskSchedulerWorkerExtensions.cs) are never invalidated when IOptionsMonitor detects options changes. The code reads options via IOptionsMonitor.Get() but does not subscribe to OnChange() to flush stale cache entries. The fix involves adding an OnChange listener that compares cache keys and disposes stale channels.

Automated fix candidate: Yes

• Well-scoped (~60-100 lines across 2 files)
• Clear fix approach: subscribe to IOptionsMonitor.OnChange, detect key changes, dispose and remove stale channels
• No breaking changes required
• Can be verified with unit tests

[github-actions]

Automated Fix Available

Branch: copilot-finds/bug/fix-options-change-cache-invalidation (view branch)
Issue: #632

Problem

gRPC channels cached in ConcurrentDictionary in the ConfigureGrpcChannel classes (both Client and Worker AzureManaged extensions) are never invalidated when IOptionsMonitor detects options changes. The code reads options via IOptionsMonitor.Get() but does not subscribe to OnChange(), so cached channels keep using stale configuration until process restart.

Root Cause

ConfigureGrpcChannel subscribes to IOptionsMonitor<T> for reading options but never calls OnChange() to detect runtime configuration changes. When options are modified (e.g., via IOptionsMonitor.OnChange triggered by configuration reloads), the cached channel continues serving the original configuration.

Fix

In both ConfigureGrpcChannel classes (Client and Worker):

1. Added IOptionsMonitorCache<T> constructor parameter to invalidate the downstream gRPC options cache
2. Subscribe to IOptionsMonitor<T>.OnChange() in the constructor to detect option changes
3. Track optionsName → cacheKey mapping in a ConcurrentDictionary<string, string> to detect when the cache key actually changes
4. In the OnChange handler: compute the new cache key, compare with the stored key, and if different: (a) remove and dispose the old channel asynchronously, (b) invalidate the IOptionsMonitorCache entry so the next resolution creates a fresh channel
5. Dispose the OnChange subscription in DisposeAsync()
6. Extracted cache key computation into a static BuildCacheKey helper method reused by both Configure() and the OnChange handler

Changed Files

• src/Client/AzureManaged/DurableTaskSchedulerClientExtensions.cs
• src/Worker/AzureManaged/DurableTaskSchedulerWorkerExtensions.cs
• test/Client/AzureManaged.Tests/DurableTaskSchedulerClientExtensionsTests.cs
• test/Worker/AzureManaged.Tests/DurableTaskSchedulerWorkerExtensionsTests.cs

Testing

Added 6 new tests (3 per Client/Worker):

1. OptionsChange_InvalidatesCachedChannel — Verifies that when options change (e.g., endpoint address), the cached gRPC channel is invalidated and a new channel is created on next resolution.
2. OptionsChangeWithSameValues_RetainsCachedChannel — Verifies that when an options reload occurs but values haven't actually changed, the existing channel is preserved (no unnecessary invalidation).
3. OptionsChange_DisposesOldChannel — Verifies that the old channel is properly shut down and disposed after invalidation.

All 125 tests in the solution pass.

Checklist

• Copyright headers on all new files
• XML documentation on all public APIs
• this. used for all member access
• Async suffix on async methods
• Private classes are sealed
• No breaking changes
• All tests pass
• No new dependencies introduced

---

To open a PR from this branch, run:

gh pr create --base main --head copilot-finds/bug/fix-options-change-cache-invalidation --title "[copilot-finds] Invalidate cached gRPC channels on options change"

[github-actions]

Verification Report

Fix Branch: copilot-finds/bug/fix-options-change-cache-invalidation (view branch)
Linked Issue: #632
Verified by: pr-verification-agent
Date: 2026-03-13T21:26:18Z
Emulator: DTS emulator (localhost:4001)

Scenario

Verified that changing DurableTaskSchedulerClientOptions or DurableTaskSchedulerWorkerOptions at runtime (via IOptionsMonitor.OnChange) causes the cached gRPC channel to be replaced with a fresh channel. Also verified that unchanged options do not cause unnecessary channel recreation.

Verification Sample

• Branch: verification/issue-632 (view branch)
• Full source: samples/Verification/Issue-632/Program.cs

Results

Check	Expected	Actual	Status
Client: options change invalidates cached channel	New channel created	New channel created	✅ PASS
Client: unchanged options retain cached channel	Same channel retained	Same channel retained	✅ PASS
Worker: options change invalidates cached channel	New channel created	New channel created	✅ PASS
Worker: unchanged options retain cached channel	Same channel retained	Same channel retained	✅ PASS

Console Output

Click to expand full output

[Check 1] Client: options change invalidates cached channel...
  PASS: Channel was invalidated after endpoint change
[Check 2] Client: unchanged options retain cached channel...
  PASS: Channel retained when options unchanged
[Check 3] Worker: options change invalidates cached channel...
  PASS: Channel was invalidated after endpoint change
[Check 4] Worker: unchanged options retain cached channel...
  PASS: Channel retained when options unchanged

=== VERIFICATION RESULT ===
Issue: #632
Scenario: gRPC channel cache invalidation on runtime options change
Checks passed: 4
Checks failed: 0
Passed: True
Timestamp: 2026-03-13T21:26:18.8758160Z
=== END RESULT ===

Conclusion

All 4 verification checks passed. The fix correctly invalidates cached gRPC channels when DurableTaskSchedulerClientOptions or DurableTaskSchedulerWorkerOptions change at runtime, and correctly retains channels when options remain unchanged. Verification sample pushed to verification/issue-632 branch.