Repository navigation
Reduce per-call SHA1 allocation in deterministic NewGuid() - #780
Open
Bernd Verst (berndverst) wants to merge 17 commits into
Open
Bernd Verst (berndverst) wants to merge 17 commits into
Bernd Verst (berndverst) wants to merge 17 commits into
Conversation
TaskOrchestrationContextWrapper.NewGuid() previously created and disposed a new SHA1 instance on every call. Since a single wrapper instance is used for the duration of one orchestration execution, and orchestrator code within that execution runs sequentially (never concurrently), the SHA1 instance can safely be cached on the wrapper and reused across calls via HashAlgorithm.Initialize(), avoiding a per-call allocation. The hashed name, DNS namespace bytes, byte-swap order, and RFC 4122 version/variant bit handling are all unchanged, so generated GUIDs are byte-for-byte identical to before this change for the same inputs. Adds regression tests asserting: - stable, golden-value deterministic GUIDs for fixed inputs - distinct GUIDs across repeated calls with the same instance/timestamp - identical GUID sequences across two independent wrapper instances given identical inputs (simulated replay) - the cached SHA1 instance is reused (not reallocated) across calls Fixes #778 Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: f9b8e1d4-b96d-41ec-adeb-a691aac6fee1
Contributor
There was a problem hiding this comment.
Pull request overview
This PR optimizes deterministic GUID generation in the Worker shim by avoiding per-call SHA1 allocations inside TaskOrchestrationContextWrapper.NewGuid(), while adding regression tests intended to protect replay compatibility and validate the optimization.
Changes:
- Cache and reuse a
SHA1instance inTaskOrchestrationContextWrapper.NewGuid()viaInitialize()to reset state between calls. - Add golden-value determinism tests and replay-sequence tests for
NewGuid(). - Extend the test
TestOrchestrationContexthelper to allow pinningInstanceIdandCurrentUtcDateTimeinputs.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| src/Worker/Core/Shims/TaskOrchestrationContextWrapper.cs | Reuses a cached SHA1 instance for deterministic GUID hashing to remove per-call allocation/disposal. |
| test/Worker/Core.Tests/Shims/TaskOrchestrationContextWrapperTests.cs | Adds deterministic GUID regression tests and enhances the test context helper to enable stable inputs. |
Address blocking review feedback on PR #780 (issue #778): 1. Cached SHA1 instance is now disposed. TaskOrchestrationContextWrapper implements IDisposable, and TaskOrchestrationShim disposes the previous wrapper right before replacing it with a new one on each replay/decision task, so the cached hash algorithm no longer accumulates undisposed instances. The base TaskOrchestration type has no disposal hook, so a documented CA1001 suppression covers the final instance per orchestration execution's lifetime, which is left for the GC/finalizer. 2. Corrected the code comment to honestly scope the optimization per TFM, verified against reference source: on .NET Framework, SHA1CryptoServiceProvider.Initialize() disposes/recreates its native CAPI handle every call, so native-handle churn is not eliminated there, only managed-side allocation. On modern .NET (net5.0+) on Windows, the CNG-based implementation can reuse and reset its native handle, so this caching also avoids native allocation on those runtimes. Added regression tests verifying Dispose() releases the cached SHA1 instance, is idempotent/safe to call without a prior NewGuid() call, and that GUID generation remains byte-identical after a mid-sequence dispose. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: f9b8e1d4-b96d-41ec-adeb-a691aac6fee1
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
Comments suppressed due to low confidence (4)
test/Worker/Core.Tests/Shims/TaskOrchestrationContextWrapperTests.cs:428
- Using DateTime.Parse(..., null, ...) makes this test depend on the current thread culture. Use CultureInfo.InvariantCulture so the golden-value regression remains stable across environments.
DateTime.Parse("2023-05-06T07:08:09.1234567Z", null, DateTimeStyles.RoundtripKind));
test/Worker/Core.Tests/Shims/TaskOrchestrationContextWrapperTests.cs:446
- Using DateTime.Parse(..., null, ...) makes this test depend on the current thread culture. Use CultureInfo.InvariantCulture so the regression remains stable across environments.
DateTime.Parse("2024-01-01T00:00:00.0000000Z", null, DateTimeStyles.RoundtripKind));
test/Worker/Core.Tests/Shims/TaskOrchestrationContextWrapperTests.cs:468
- Using DateTime.Parse(..., null, ...) makes this test depend on the current thread culture. Use CultureInfo.InvariantCulture so the replay regression remains stable across environments.
DateTime timestamp = DateTime.Parse("2022-11-11T11:11:11.1111111Z", null, DateTimeStyles.RoundtripKind);
test/Worker/Core.Tests/Shims/TaskOrchestrationContextWrapperTests.cs:576
- Using DateTime.Parse(..., null, ...) makes this test depend on the current thread culture. Use CultureInfo.InvariantCulture so the golden-value regression remains stable across environments.
DateTime.Parse("2023-05-06T07:08:09.1234567Z", null, DateTimeStyles.RoundtripKind));
TaskOrchestrationShim.Execute() runs exactly once per shim instance in every real call site; extended-session resumption reuses the cached executor via TaskOrchestrationExecutor.ExecuteNewEvents() and never calls Execute() again. This meant the round-2 fix (disposing the *previous* wrapper inside Execute() before replacing it) never actually freed the *final* cached SHA1 for normal execution or for extended sessions, leaking a native hash handle per orchestration instance until GC/finalization. This introduces deterministic ownership-based disposal instead: - TaskOrchestrationShim now implements IDisposable directly (the defensive dispose-previous-wrapper logic in Execute() is kept as a safety net but documented as effectively unreachable for current callers). - GrpcDurableTaskWorker's processor wraps shim construction/execution in try/finally and disposes the shim once its single work item completes. - GrpcOrchestrationRunner disposes the shim immediately when it is not handed off to the extended-session cache (completed on first execution, or the request isn't part of an extended session), and registers a PostEvictionCallbackRegistration on cached entries so the shim is disposed exactly once whenever the cache entry is evicted for any reason (explicit Remove, sliding-expiration timeout, capacity eviction, or cache disposal) -- never while the orchestration may still resume. No generated GUID bytes, algorithm, namespace, endianness, version bits, target frameworks, or public API are changed. Tests added: - TaskOrchestrationShimTests: Dispose() forwards to and actually releases the wrapper's cached SHA1 (ObjectDisposedException on reuse), is a no-op when Execute() was never called, and is idempotent across repeated calls. - GrpcOrchestrationRunnerTests: extended-session cache eviction via explicit removal and via sliding-expiration timeout both dispose the cached shim's SHA1, using reflection (no InternalsVisibleTo from this assembly) to reach the private wrapperContext/cachedHashAlgorithm fields via the public ExtendedSessionState.TaskOrchestration property. Verified: Worker.Tests 145/145 passed, Worker.Grpc.Tests 139/139 passed (including new eviction tests). Fixes #778 Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: f9b8e1d4-b96d-41ec-adeb-a691aac6fee1
Addresses three remaining Medium lifecycle issues from round-4 review of PR #780: 1. ExtendedSessionsCache.Dispose() now calls MemoryCache.Clear() before Dispose(). Confirmed against the pinned Microsoft.Extensions.Caching.Memory 8.0.1 source that MemoryCache.Dispose() alone does NOT invoke post-eviction callbacks for entries still present in the cache -- only Clear(), Remove(), and the internal capacity/expiration removal paths do. Without this fix, any extended session still cached at worker shutdown would leak its cached shim (and SHA1 instance). 2. GrpcOrchestrationRunner's direct-execution path now wraps TaskOrchestrationExecutor construction/Execute()/cache Set() in try/finally, using a transferredShimToCache flag to gate disposal. If Execute() (or the subsequent Set() call) throws before the shim's ownership is transferred to the extended-sessions cache, the shim is now still deterministically disposed in finally instead of leaking. 3. The round-3 eviction-disposal tests asserted disposal immediately after triggering an eviction/removal, but MemoryCache dispatches post-eviction callbacks via Task.Factory.StartNew (i.e. asynchronously, on a background thread), so this was a latent race. Added a bounded polling helper (WaitUntilDisposedAsync) used by both existing tests, and added a new regression test (ExtendedSessionsCache_Dispose_DisposesCachedShimResources) proving that disposing the cache itself while an extended session is still pending disposes the cached shim's resources. Verified: - Worker.Tests: 145/145 passed - Worker.Grpc.Tests: 140/140 passed (139 + 1 new) Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: f9b8e1d4-b96d-41ec-adeb-a691aac6fee1
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.
Comments suppressed due to low confidence (6)
src/Worker/Core/Shims/TaskOrchestrationContextWrapper.cs:42
- The comment implies the cached SHA1 is disposed primarily when the shim replaces the wrapper in a subsequent Execute call, but the actual primary ownership boundary is TaskOrchestrationShim.Dispose() (and cache eviction) once the shim is no longer usable. Updating this comment will prevent confusion about when disposal happens.
// This instance is disposed via Dispose() (see TaskOrchestrationShim, which disposes the previous
// wrapper before replacing it with a new one on the next replay/decision task).
test/Worker/Core.Tests/Shims/TaskOrchestrationContextWrapperTests.cs:405
- These tests parse a fixed, culture-invariant ISO-8601 timestamp but pass a null IFormatProvider, which makes the parse behavior depend on CurrentCulture. Using CultureInfo.InvariantCulture keeps the test independent of machine culture settings.
DateTime.Parse("2023-05-06T07:08:09.1234567Z", null, DateTimeStyles.RoundtripKind));
test/Worker/Core.Tests/Shims/TaskOrchestrationContextWrapperTests.cs:428
- These tests parse a fixed, culture-invariant ISO-8601 timestamp but pass a null IFormatProvider, which makes the parse behavior depend on CurrentCulture. Using CultureInfo.InvariantCulture keeps the test independent of machine culture settings.
DateTime.Parse("2023-05-06T07:08:09.1234567Z", null, DateTimeStyles.RoundtripKind));
test/Worker/Core.Tests/Shims/TaskOrchestrationContextWrapperTests.cs:446
- These tests parse a fixed, culture-invariant ISO-8601 timestamp but pass a null IFormatProvider, which makes the parse behavior depend on CurrentCulture. Using CultureInfo.InvariantCulture keeps the test independent of machine culture settings.
DateTime.Parse("2024-01-01T00:00:00.0000000Z", null, DateTimeStyles.RoundtripKind));
test/Worker/Core.Tests/Shims/TaskOrchestrationContextWrapperTests.cs:468
- This test parses a fixed, culture-invariant ISO-8601 timestamp but passes a null IFormatProvider, which makes the parse behavior depend on CurrentCulture. Using CultureInfo.InvariantCulture keeps the test independent of machine culture settings.
DateTime timestamp = DateTime.Parse("2022-11-11T11:11:11.1111111Z", null, DateTimeStyles.RoundtripKind);
test/Worker/Core.Tests/Shims/TaskOrchestrationContextWrapperTests.cs:576
- These tests parse a fixed, culture-invariant ISO-8601 timestamp but pass a null IFormatProvider, which makes the parse behavior depend on CurrentCulture. Using CultureInfo.InvariantCulture keeps the test independent of machine culture settings.
DateTime.Parse("2023-05-06T07:08:09.1234567Z", null, DateTimeStyles.RoundtripKind));
Round-5 fix: MemoryCache.Clear() (added in round 4 to force eviction callbacks to run before shutdown) throws ObjectDisposedException if called on an already-disposed MemoryCache. Since Dispose() was not guarded against repeat calls, invoking it twice (e.g. duplicate shutdown hooks, or concurrent shutdown paths) would throw instead of being a safe no-op. - Add an `int disposed` field guarded via `Interlocked.Exchange(ref this.disposed, 1) != 0` at the top of Dispose(), making it both idempotent (repeat calls short-circuit) and thread-safe (concurrent calls only let one caller proceed). - Clarify the disposal comment: Clear() only guarantees eviction callbacks are scheduled (via Task.Factory.StartNew) before Dispose() returns, not that they have completed. - Add ExtendedSessionsCache_Dispose_CalledMultipleTimes_DoesNotThrow (sequential double-dispose) and ExtendedSessionsCache_Dispose_CalledConcurrently_DoesNotThrow (8-thread concurrent dispose) regression tests. Verified: targeted GrpcOrchestrationRunnerTests 17/17, full Worker.Grpc.Tests 142/142, full Worker.Tests 145/145. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: f9b8e1d4-b96d-41ec-adeb-a691aac6fee1
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 8 out of 8 changed files in this pull request and generated 1 comment.
Comments suppressed due to low confidence (1)
test/Worker/Grpc.Tests/GrpcOrchestrationRunnerTests.cs:499
- This comment says eviction/removal "should synchronously invoke" the eviction callback, but the test’s earlier note (and the helper name) correctly explain that MemoryCache dispatches post-eviction callbacks asynchronously. The wording here is misleading and could cause future contributors to reintroduce racy assertions.
// Now set the extended session flag to false for this instance, which removes/evicts the cache
// entry and should synchronously invoke the eviction callback that disposes the cached shim.
orchestratorRequest.Properties.Clear();
…review) - Replace the round-5 Interlocked.Exchange disposed flag with a shared syncRoot lock guarding both Dispose() and GetOrInitializeCache(). This closes a race where Dispose() could observe an uninitialized cache field, mark itself disposed, and return -- while a concurrent GetOrInitializeCache() call then lazily constructed a brand-new MemoryCache that would never be disposed (since disposed was already permanently true), permanently leaking it. - GetOrInitializeCache() now throws ObjectDisposedException immediately if called after Dispose(), instead of possibly returning an already-disposed MemoryCache or racing to create an unreachable one. - Dispose() clears the extendedSessions field to null under the lock before tearing down the captured local reference outside the lock (avoids holding the lock during Clear()/Dispose(), which is safe since the eviction callback never calls back into ExtendedSessionsCache). - Add ExtendedSessionsCache_DisposeRaceWithGetOrInitializeCache_NeverLeaksCache, racing Dispose() against GetOrInitializeCache() across many iterations and asserting the returned cache (if any) is provably disposed, and that a repeated Dispose() call remains a safe no-op. - Fix a stale comment in ExternallyEndedExtendedSession_Evicted_DisposesCachedShimResources claiming the eviction callback fires synchronously; it is dispatched asynchronously and the test already awaits WaitUntilDisposedAsync. - Use CultureInfo.InvariantCulture instead of null for the DateTime.Parse format provider in the NewGuid() golden-value regression tests, removing any dependency on the test runner's current culture. Verified: targeted GrpcOrchestrationRunnerTests 18/18, full Worker.Grpc.Tests 143/143, full Worker.Tests 145/145 (golden GUID values unchanged after the culture fix). Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: f9b8e1d4-b96d-41ec-adeb-a691aac6fee1
- Add two deterministic (non-racy) tests asserting GetOrInitializeCache() throws ObjectDisposedException after Dispose(), covering both the never-initialized and already-initialized cache scenarios. - Rewrite the Dispose()/GetOrInitializeCache() race stress test to use a Barrier(2) so both competing tasks start racing at (approximately) the same instant, instead of relying on Task.Run queue-order bias which let the 'init wins' ordering dominate and never genuinely exercise the 'dispose wins' path. Track and assert that both orderings actually occurred across the 50 iterations. - Add a new deterministic ExtendedSessionsCache_Dispose_DisposesCachedEntryExactlyOnce test using a CountingDisposable spy wired up with the same PostEvictionCallbackRegistration pattern GrpcOrchestrationRunner uses for real cached shims, proving exact-once disposal of cached content tied to eviction (not just that the owning MemoryCache object becomes unusable). This is intentionally separate from the racing stress test: racing a Set() call concurrently against Dispose()'s internal Clear()/Dispose() split introduces a narrow window where an entry added in between is never evicted by that cache instance -- a test-harness artifact, not a production scenario. No production code changes in this round; NewGuid determinism, cache handoff exception cleanup, and eviction/shutdown lifecycle already passed final review. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: f9b8e1d4-b96d-41ec-adeb-a691aac6fee1
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.
Comments suppressed due to low confidence (2)
src/Worker/Core/Shims/TaskOrchestrationContextWrapper.cs:464
HashAlgorithm.Hashis nullable; if it ever returns null,Array.Copywill throw aNullReferenceException. Since this code requires a hash afterTransformFinalBlock, add an explicit null-check (or null-forgiving with justification) to make the contract explicit and avoid nullable warnings.
byte[] hashByteArray = hashAlgorithm.Hash;
test/Worker/Core.Tests/Shims/TaskOrchestrationContextWrapperTests.cs:708
- This nested test context type is private and not designed for inheritance. To follow the repo guideline of sealing private non-base classes, consider making it
sealed.
class TestOrchestrationContext : OrchestrationContext
The Dispose()/GetOrInitializeCache() race stress test asserted that both the 'init wins' and 'dispose wins' orderings occurred at least once across 50 Barrier-coordinated iterations. A Barrier release does not guarantee fair or varying thread-pool scheduling, so correct, race-free code could legitimately let the same side win every iteration -- making this assertion's pass/fail outcome probabilistic and CI-flaky rather than a genuine correctness check. Remove the win-count tracking and both-orderings-required assertions. The test still asserts the invariants that must hold under every possible interleaving: a cache handed back by GetOrInitializeCache() before a concurrent Dispose() completes is provably disposed (TryGetValue throws ObjectDisposedException), and repeated Dispose() calls remain a safe, idempotent no-op. Also give each Barrier.SignalAndWait() a bounded timeout instead of waiting indefinitely, so a hung/stalled participant surfaces as a test failure (TimeoutException) rather than hanging the test run. The deterministic post-dispose contract tests (GetOrInitializeCache_AfterDispose*) and the deterministic exact-once disposal test (ExtendedSessionsCache_Dispose_DisposesCachedEntryExactlyOnce) are unchanged and continue to directly catch the original leak. No production code changes in this round. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: f9b8e1d4-b96d-41ec-adeb-a691aac6fee1
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 01dc5b7c-c742-45b7-ae8c-5cda9bcfbd2c
![github-code-quality[bot]](https://avatars.githubusercontent.com/u/9919?s=60&v=4){kind=small}
halspang
reviewed
Jul 31, 2026
halspang
left a comment
halspang
left a comment
Member
There was a problem hiding this comment.
This seems like it adds a lot of additional complexity (especially around extended sessions). All that complexity seems to stem from being able to properly dispose the cached SHA1?
Given the code has to initialize the SHA1 anyway, are we really saving anything here? At the very least the complexity is now much worse.
Also, since this was already deterministic, I'm not sure why we need two paths with it cached and not? Does it actually impact an in-progress orchestration to suddenly cache its SHA?
Member
Author
Quantitative performance impactI compared live head
The allocation relationship is deterministic in this benchmark: reuse avoids 128 B for every SHA1 instance after the first, so the GUID-only saving is Extended-session bookkeepingThe stronger ownership model is a fixed investment that enables safe reuse. An extracted success-path benchmark measured:
Combining those measurements, rather than treating the cache work as a standalone regression:
At the measured marginal saving, about six reused calls after the first (seven total GUIDs) amortize one ownership cycle for both CPU and allocation. Lifetimes below that point can be a net loss; high-GUID replay and extended-session workloads receive the material gain. Memory and scope
These are isolated, environment-specific measurements. Whole-worker latency/throughput gains will be smaller in proportion to how much time a workload spends generating deterministic GUIDs. |
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 01dc5b7c-c742-45b7-ae8c-5cda9bcfbd2c
Member
Author
|
halspang The complexity is indeed ownership/disposal rather than determinism. The two paths are intentional because the public factory returns |
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 01dc5b7c-c742-45b7-ae8c-5cda9bcfbd2c
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 14 out of 14 changed files in this pull request and generated no new comments.
Suppressed comments (1)
src/Worker/Core/ExtendedSessionsCache.cs:68
- ExtendedSessionsCache.Dispose() calls MemoryCache.Clear() unconditionally. Because GetOrInitializeCache() exposes the underlying MemoryCache publicly, a consumer can dispose it directly (your own code already handles this possibility elsewhere). If that happens, Clear() will throw ObjectDisposedException, causing ExtendedSessionsCache.Dispose() to throw during shutdown/cleanup even though Dispose() should be best-effort and non-throwing.
cacheToDispose?.Clear();
cacheToDispose?.Dispose();
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 14 out of 14 changed files in this pull request and generated no new comments.
Suppressed comments (1)
src/Worker/Core/ExtendedSessionsCache.cs:68
- ExtendedSessionsCache.Dispose() calls MemoryCache.Clear() and Dispose() directly. Because GetOrInitializeCache() returns the underlying MemoryCache publicly, external callers can dispose it independently; in that case, Clear() (and potentially Dispose()) can throw ObjectDisposedException, causing ExtendedSessionsCache.Dispose() itself to throw. Dispose implementations should be resilient and avoid throwing when the inner cache is already disposed.
cacheToDispose?.Clear();
cacheToDispose?.Dispose();
Use conditional SHA1 ownership for per-call disposal and document that the extended-session wrapper retains ownership of its returned cache. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 01dc5b7c-c742-45b7-ae8c-5cda9bcfbd2c
Member
Author
|
I also evaluated the suppressed suggestion to swallow |
Preserve canceled-event and deterministic GUID regressions; verify managed-lifetime allocation savings without changing GUID sequences. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
🔵 Needs a closer look
The generation-based ownership protocol spans concurrent runner handoff, asynchronous cache eviction callbacks, shutdown, and direct cache access, so remaining interleavings and exactly-once disposal behavior require maintainer/runtime validation.
No open issues 🎉
Review effort: Lite
9 of 15 tasks
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
What changed?
NewGuid()calls only on internal worker-owned orchestration shims, and dispose it at the owning execution/cache boundary.DurableTaskShimFactory.CreateOrchestrationoverloads resource-neutral: they still create and dispose SHA1 per call, without imposing a hidden disposal obligation through theTaskOrchestrationreturn type.mainat936325b2. Resolve the test conflict by retaining both deterministic-GUID coverage and main's canceled external-event/continue-as-new regressions.Why is this change needed?
Issues / work items
Project checklist
release_notes.mdAI-assisted code disclosure (required)
Was an AI tool used? (select one)
If AI was used:
AI verification (required if AI was used):
Testing
Automated tests
dotnet restore Microsoft.DurableTask.sln --configfile nuget.config --verbosity quiet— passed. Required after the merge to refresh stale DurableTask.Core dependency assets.dotnet test test\Worker\Core.Tests\Worker.Tests.csproj --configuration Release --no-restore --verbosity quiet— passed, 170/170, including allocation reduction and golden GUID/replay coverage.dotnet test test\Worker\Grpc.Tests\Worker.Grpc.Tests.csproj --configuration Release --no-restore --verbosity quiet -p:WarningLevel=0— passed, 218/218, including ownership, eviction, shutdown, and entity runner coverage.dotnet test test\Grpc.IntegrationTests\Grpc.IntegrationTests.csproj --configuration Release --no-restore --filter "FullyQualifiedName~OrchestrationPatterns|FullyQualifiedName~TracingIntegrationTests" --verbosity quiet -p:WarningLevel=0— passed, 54/54.dotnet build src\Worker\Grpc\Worker.Grpc.csproj --configuration Release --no-restore --verbosity quiet -p:WarningLevel=0— passed for all configured target frameworks.Manual validation (only if runtime/behavior changed)
c068aec9.Notes for reviewers
MemoryCache.Clear()schedules eviction callbacks asynchronously; cache disposal does not promise that every callback has finished before returning.usingis unsafe where ownership transfers to the extended-session cache, and retaining the wrapper reference preservesGetStatusbehavior while its owned SHA1 is cleared.