test: stabilize multi-grain cancellation

[ReubenBond]

MultipleGrainsTaskCancellation can complete caller-side cancellation before one or more delayed requests begin executing. The test then waits for grain-side cancellation evidence which can never exist, producing the five-minute timeout seen on macOS.

Use the start-notification barrier added by #10461 for each delayed grain call before cancelling the shared token. Assigning each grain a distinct evidence ID lets the test prove that all five calls started and observed cancellation, while the zero-delay cases retain pre-start cancellation coverage.

Fixes #10439
Fixes #10440

Microsoft Reviewers: Open in CodeFlow

[Copilot]

Pull request overview

Stabilizes the MultipleGrainsTaskCancellation BVT by ensuring delayed interleaving calls have actually started executing on the grain before the shared cancellation token is triggered, preventing “wait for evidence which can never exist” timeouts (notably on macOS).

Changes:

• Introduces per-grain callId values to disambiguate cancellation evidence across multiple grains.
• Uses the start-notification barrier (LongWaitInterleavingWithStartNotification + observer) for delayed cases before scheduling cancellation.
• Preserves the zero-delay path to continue exercising caller-side pre-start cancellation behavior.

Show a summary per file

File	Description
test/Orleans.Runtime.Tests/CancellationTests/CancellationTokenTests.cs	Updates the multi-grain cancellation test to wait for grain-side start notifications and to track cancellation evidence per grain call.

Review details

Tip

Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

• Files reviewed: 1/1 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

Review details

Suppressed comments (1)

test/Orleans.Runtime.Tests/CancellationTests/CancellationTokenTests.cs:114

• observer/observerReference are created and the object reference is registered even when delay == 0, but in that branch the reference is never used (the call path uses LongWaitInterleaving rather than the ...WithStartNotification overload). This adds unnecessary runtime work and can slightly perturb the zero-delay (pre-start cancellation) scenario. Consider creating/deleting the observer reference only when delay > 0.

        var callIds = grains.Select(_ => Guid.NewGuid()).ToArray();
        var observer = new LongRunningTaskObserver();
        var observerReference = fixture.GrainFactory.CreateObjectReference<ILongRunningTaskObserver>(observer);
        try

• Files reviewed: 1/1 changed files
• Comments generated: 0 new
• Review effort level: Lite