Add support for cancelling regular hub invocations from client #64098

Copilot · 2025-10-17T19:44:01Z

Summary

This PR implements cancellation of long-running hub methods from the client, as requested in issue #11542.

Changes Made (updated after review):

Client-side (HubConnection.cs):

Extracted duplicate cancellation logic into CancelInvocationAsync private method (used by both regular invocations and streaming)
Updated both InvokeCoreAsyncCore and StreamAsChannelCoreAsyncCore to use the extracted method

Server-side (HubMethodDescriptor.cs):

Updated to allow CancellationToken as a synthetic argument for all hub methods

Server-side (DefaultHubDispatcher.cs):

Updated ExecuteInvocation to register CancellationTokenSource in ActiveRequestCancellationSources
Uses new log method CancelInvocation for the generic case

Logging (DefaultHubDispatcherLog.cs):

Created new log methods (CancelInvocation with ID 26, UnexpectedCancelWithId with ID 27) to avoid breaking existing EventName/Id
Kept old methods for backward compatibility
Updated messages to be more generic ("invocation or stream" instead of just "stream")

Server-side (HubConnectionContext.cs):

Updated comment on ActiveRequestCancellationSources from "Currently used only for streaming methods" to "Used to cancel hub invocations and streaming methods"

Tests:

Added client-side test to verify CancelInvocationMessage is sent for regular invocations
Added server-side test hub method and test to verify CancellationToken works for regular invocations

All tests pass except for one flaky test (UploadStreamCancellationSendsStreamComplete) that passes in isolation but fails when run with all tests. This appears to be a test pollution/ordering issue unrelated to the core functionality being added.

Original prompt

This section details on the original issue you should resolve

<issue_title>[SignalR] Possibility to cancel long running hub method from client</issue_title>
<issue_description>I´m not quit sure if this post is more of a question or a feature request.

I noticed that the InvokeAsync<TResult>(HubConnection, String, CancellationToken) method accepts a CancellationToken. As far as I understood this token only cancels the invocation (and waiting for a result, ...) on the client, while on the server side the method proceeds.
Is this correct?

If so wouldn´t it be a nice feature to allow such a cancellation? I saw that Google offers this possibility in their gRPC framework aswell:

Cancelling RPCs
Either the client or the server can cancel an RPC at any time. A cancellation terminates the RPC immediately so that no further work is done. It is not an “undo”: changes made before the cancellation will not be rolled back.

When my understanding is wrong please provide me an example on how to do a cancellation of long running hub methods from the client.</issue_description>

<agent_instructions>See comment in #11542 (comment)</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@davidfowl Today we only support cancellation for streams but there's nothing wrong with supporting this for other invocations. @BrennanConroy @anurse I don't think we do support that, but we structured the code in such a way that we could add support for it in the future. @ We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our [Triage Process](https://github.com/dotnet/aspnetcore/blob/master/docs/TriageProcess.md). @davidfowl @muzopraha What's the scenario you have with a long running hub method? @davidfowl @thorgeirk11 No updates, best to add your scenario so we have a record of what people want to use it for before we invest the time. @BrennanConroy File a new issue and show your code. @BrennanConroy CancellationToken in the hub method signature is only supported for Server to client streaming currently.

This issue is tracking adding it for other cases.</comment_new>
<comment_new>@BrennanConroy
Since this feature isn't implemented yet that method signature won't work. It's basically trying to receive a serialized CancellationToken from the client, which isn't going to work.

The cancellation token in InvokeAsync will cancel the client waiting for a server response, but it doesn't pass that info along to the server yet. That's what this issue is tracking adding support for.

public async Task UpdateChannelAsync(TPMChannels channel, CancellationToken cts = default) ->
public async Task UpdateChannelAsync(TPMChannels channel)</comment_new>
<comment_new>@davidfowl
I'll defer to @BrennanConroy here.</comment_new>
<comment_new>@BrennanConroy
Basically we would need to update the client(s) to send a CancelInvocationMessage when the cancellation token passed in to InvokeAsync is canceled.
We currently only send that message type when the client cancels a stream

aspnetcore/src/SignalR/clients/csharp/Client.Core/src/HubConnection.cs

Line 708 in 54c0cc8

    
           await SendHubMessage(_state.CurrentConnectionStateUnsynchronized, new CancelInvocationMessage(irq.InvocationId), cancellationToken: default).ConfigureAwait(false);

The server is mostly setup to handle CancelInvocationMessage

aspnetcore/src/SignalR/server/Core/src/Internal/DefaultHubDispatcher.cs

Lines 183 to 189 in 54c0cc8

    
           case CancelInvocationMessage cancelInvocationMessage: 
        
               // Check if there is an associated active stream and cancel it if it exists. 
        
               // The cts will be removed when the streaming method completes executing 
        
               if (connection.ActiveRequestCancellationSources.TryGetValue(cancelInvocationMessage.InvocationId!, out var cts)) 
        
               { 
        
                   Log.CancelStream(_logger, cancelInvocationMessage.InvocationId!); 
        
                   cts.Cancel();

The logs would likely need to be updated since it assumes streams are the only thing that can be canceled.

We'd also need to update the logic around which hub methods can have a synthetic argument (CancellationToken)

aspnetcore/src/SignalR/server/Core/src/Internal/HubMethodDescriptor.cs

Lines 64 to 66 in 54c0cc8

    
           if (IsStreamResponse && p.ParameterType == typeof(CancellationToken)) 
        
           { 
        
               HasSyntheticArguments = true;

A massive stretch goal would be to do the same thing for client results, which would require adding synthetic argument support on the client side and sending CancelInvocationMessage from the server. That work is tracked by #44831 and shouldn't restrict this issue from being worke...

Fixes #11542

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

Co-authored-by: BrennanConroy <[email protected]>

…fying comment Co-authored-by: BrennanConroy <[email protected]>

BrennanConroy

@copilot Update the comment on HubConnectionContext.ActiveRequestCancellationSources as well

BrennanConroy · 2025-10-17T23:34:39Z

src/SignalR/clients/csharp/Client.Core/src/HubConnection.cs


    private async Task<object?> InvokeCoreAsyncCore(string methodName, Type returnType, object?[] args, CancellationToken cancellationToken)
    {
+        async Task OnInvocationCanceled(InvocationRequest irq)


Looks like this code is the exact same as the code used for streaming. We should extract it into a private method and call that method from here and the streaming method.

Done in commit 0ad2858. Extracted the duplicate cancellation logic into a CancelInvocationAsync private method that's now used by both InvokeCoreAsyncCore and StreamAsChannelCoreAsyncCore.

BrennanConroy · 2025-10-20T18:32:22Z

src/SignalR/server/Core/src/Internal/DefaultHubDispatcherLog.cs


-    [LoggerMessage(11, LogLevel.Debug, "CancelInvocationMessage received unexpectedly.", EventName = "UnexpectedCancel")]
-    public static partial void UnexpectedCancel(ILogger logger);
+    [LoggerMessage(11, LogLevel.Debug, "CancelInvocationMessage received for {InvocationId} but invocation was not found.", EventName = "UnexpectedCancel")]


Suggested change

[LoggerMessage(11, LogLevel.Debug, "CancelInvocationMessage received for {InvocationId} but invocation was not found.", EventName = "UnexpectedCancel")]

[LoggerMessage(11, LogLevel.Debug, "CancelInvocationMessage received for {InvocationId} but invocation or stream was not found.", EventName = "UnexpectedCancel")]

Done in commit 0ad2858. Created a new log method UnexpectedCancelWithId (ID 27) with the suggested message "...invocation or stream was not found." to avoid changing the existing EventName.

BrennanConroy · 2025-10-20T18:37:35Z

src/SignalR/server/Core/src/Internal/DefaultHubDispatcherLog.cs


-    [LoggerMessage(10, LogLevel.Debug, "Canceling stream for invocation {InvocationId}.", EventName = "CancelStream")]
-    public static partial void CancelStream(ILogger logger, string invocationId);
+    [LoggerMessage(10, LogLevel.Debug, "Canceling invocation {InvocationId}.", EventName = "CancelInvocation")]


We can't change existing logs' EventName or Id. So let's make a new log for the more generic "CancelInvocation" log. Also might want to mention "Canceling invocation or stream {InvocationId}."

Done in commit 0ad2858. Created a new log method CancelInvocation (ID 26) with message "Canceling invocation or stream {InvocationId}." The old CancelStream method (ID 10) is kept for backward compatibility.

…comment Co-authored-by: BrennanConroy <[email protected]>

Copilot · 2025-10-20T18:58:48Z

@copilot Update the comment on HubConnectionContext.ActiveRequestCancellationSources as well

Done in commit 0ad2858. Updated the comment from "Currently used only for streaming methods" to "Used to cancel hub invocations and streaming methods".

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

fakeurl.org
- Triggering command: /home/REDACTED/work/aspnetcore/aspnetcore/.dotnet/dotnet exec --runtimeconfig /home/REDACTED/work/aspnetcore/aspnetcore/artifacts/bin/Microsoft.AspNetCore.SignalR.Client.Tests/Debug/net10.0/Microsoft.AspNetCore.SignalR.Client.Tests.runtimeconfig.json --depsfile /home/REDACTED/work/aspnetcore/aspnetcore/artifacts/bin/Microsoft.AspNetCore.SignalR.Client.Tests/Debug/net10.0/Microsoft.AspNetCore.SignalR.Client.Tests.deps.json /home/REDACTED/work/aspnetcore/aspnetcore/artifacts/bin/Microsoft.AspNetCore.SignalR.Client.Tests/Debug/net10.0/testhost.dll --port 34169 --endpoint 127.0.0.1:034169 --role client --parentprocessid 8506 --telemetryoptedin false (dns block)
- Triggering command: /home/REDACTED/work/aspnetcore/aspnetcore/.dotnet/dotnet exec --runtimeconfig /home/REDACTED/work/aspnetcore/aspnetcore/artifacts/bin/Microsoft.AspNetCore.SignalR.Client.Tests/Debug/net10.0/Microsoft.AspNetCore.SignalR.Client.Tests.runtimeconfig.json --depsfile /home/REDACTED/work/aspnetcore/aspnetcore/artifacts/bin/Microsoft.AspNetCore.SignalR.Client.Tests/Debug/net10.0/Microsoft.AspNetCore.SignalR.Client.Tests.deps.json /home/REDACTED/work/aspnetcore/aspnetcore/artifacts/bin/Microsoft.AspNetCore.SignalR.Client.Tests/Debug/net10.0/testhost.dll --port 38457 --endpoint 127.0.0.1:038457 --role client --parentprocessid 10541 --telemetryoptedin false (dns block)
- Triggering command: /home/REDACTED/work/aspnetcore/aspnetcore/.dotnet/dotnet exec --runtimeconfig /home/REDACTED/work/aspnetcore/aspnetcore/artifacts/bin/Microsoft.AspNetCore.SignalR.Client.Tests/Debug/net10.0/Microsoft.AspNetCore.SignalR.Client.Tests.runtimeconfig.json --depsfile /home/REDACTED/work/aspnetcore/aspnetcore/artifacts/bin/Microsoft.AspNetCore.SignalR.Client.Tests/Debug/net10.0/Microsoft.AspNetCore.SignalR.Client.Tests.deps.json /home/REDACTED/work/aspnetcore/aspnetcore/artifacts/bin/Microsoft.AspNetCore.SignalR.Client.Tests/Debug/net10.0/testhost.dll --port 34751 --endpoint 127.0.0.1:034751 --role client --parentprocessid 12687 --telemetryoptedin false (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

Configure Actions setup steps to set up my environment, which run before the firewall is enabled
Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Initial plan

84205e7

Copilot AI assigned Copilot and BrennanConroy Oct 17, 2025

This comment was marked as outdated.

Sign in to view

dotnet-policy-service bot added the Attention: Shared Code Modified label Oct 17, 2025

BrennanConroy removed the Attention: Shared Code Modified label Oct 17, 2025

Copilot started work on behalf of BrennanConroy October 17, 2025 19:44 View session

Copilot AI and others added 3 commits October 17, 2025 19:55

Implement cancellation of regular hub invocations from client

db1c426

Co-authored-by: BrennanConroy <[email protected]>

Add tests for hub method cancellation and fix server-side registration

c618b86

Co-authored-by: BrennanConroy <[email protected]>

Address code review feedback - add null-forgiving operators and clari…

e410c32

…fying comment Co-authored-by: BrennanConroy <[email protected]>

Copilot AI changed the title ~~[WIP] Add cancellation capability to long running hub methods~~ Add support for cancelling regular hub invocations from client Oct 17, 2025

Copilot AI requested a review from BrennanConroy October 17, 2025 20:11

Copilot finished work on behalf of BrennanConroy October 17, 2025 20:11

This was referenced Oct 17, 2025

Helix failure EPT_S_NOT_REGISTERED #57416

Open

There are no more endpoints available from the endpoint mapper. dotnet/dnceng#3844

Open

BrennanConroy reviewed Oct 20, 2025

View reviewed changes

Copilot started work on behalf of BrennanConroy October 20, 2025 18:38 View session

Address PR feedback: extract duplicate code, update logging, and fix …

5e1f150

…comment Co-authored-by: BrennanConroy <[email protected]>

Copilot AI requested a review from BrennanConroy October 20, 2025 18:59

Copilot finished work on behalf of BrennanConroy October 20, 2025 18:59

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Add support for cancelling regular hub invocations from client #64098

Add support for cancelling regular hub invocations from client #64098

Copilot AI commented Oct 17, 2025 •

edited

Loading

Uh oh!

This comment was marked as outdated.

BrennanConroy left a comment

Uh oh!

BrennanConroy Oct 17, 2025

Uh oh!

Copilot AI Oct 20, 2025

Uh oh!

BrennanConroy Oct 20, 2025

Uh oh!

Copilot AI Oct 20, 2025

Uh oh!

BrennanConroy Oct 20, 2025

Uh oh!

Copilot AI Oct 20, 2025

Uh oh!

Copilot AI commented Oct 20, 2025 •

edited

Loading

I tried to connect to the following addresses, but was blocked by firewall rules:

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

	case CancelInvocationMessage cancelInvocationMessage:
	// Check if there is an associated active stream and cancel it if it exists.
	// The cts will be removed when the streaming method completes executing
	if (connection.ActiveRequestCancellationSources.TryGetValue(cancelInvocationMessage.InvocationId!, out var cts))
	{
	Log.CancelStream(_logger, cancelInvocationMessage.InvocationId!);
	cts.Cancel();

	if (IsStreamResponse && p.ParameterType == typeof(CancellationToken))
	{
	HasSyntheticArguments = true;

	[LoggerMessage(11, LogLevel.Debug, "CancelInvocationMessage received for {InvocationId} but invocation was not found.", EventName = "UnexpectedCancel")]
	[LoggerMessage(11, LogLevel.Debug, "CancelInvocationMessage received for {InvocationId} but invocation or stream was not found.", EventName = "UnexpectedCancel")]

Add support for cancelling regular hub invocations from client #64098

Are you sure you want to change the base?

Add support for cancelling regular hub invocations from client #64098

Conversation

Copilot AI commented Oct 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes Made (updated after review):

Comments on the Issue (you are @copilot in this section)

Uh oh!

This comment was marked as outdated.

BrennanConroy left a comment

Choose a reason for hiding this comment

Uh oh!

BrennanConroy Oct 17, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Oct 20, 2025

Choose a reason for hiding this comment

Uh oh!

BrennanConroy Oct 20, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Oct 20, 2025

Choose a reason for hiding this comment

Uh oh!

BrennanConroy Oct 20, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI Oct 20, 2025

Choose a reason for hiding this comment

Uh oh!

Copilot AI commented Oct 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

I tried to connect to the following addresses, but was blocked by firewall rules:

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Copilot AI commented Oct 17, 2025 •

edited

Loading

Copilot AI commented Oct 20, 2025 •

edited

Loading