Support CancellationToken on Hub methods?

[martincostello]

I've just been playing around with the new SignalR RC1 bits, and copying a pattern from MVC I added an optional CancellationToken cancellationToken = default parameter to the end of my Hub class' method to pass through into a service to do something.

With the method declared as thus, trying to send a message from the JavaScript client did not hit the breakpoint I'd set in the hub. Removing this parameter and re-running the code hit the breakpoint.

So this leads me to ask a couple of questions:

1. Is this a valid use-case in the first place compared to HTTP in MVC controllers?
2. If this is a valid use-case, is this something coming in 2.1 for RTM (or some future release)?
3. Is there something already accessible to Hub that can be used to pass to other code called by hub methods that's more useful than CancellationToken in lieu of the equivalent Controller scenario?

I've seen a view recently merged PRs related to cancellation tokens (e.g. #2101), but I wasn't sure whether that was just internally plumbing, rather than something to enable a scenario like this.

[analogrelay]

Yeah, this is something we've talked about, but it does work a little differently from MVC. In MVC, the token is bound to when the Request ends (i.e. the connection closes). In SignalR, you generally want a way to trigger cancellation from the client. We've talked about ways of doing this but didn't come to a conclusion in time for 2.1. We'll look at it moving forward, but we don't have any plans to support this in 2.1.

[martincostello]

Cool, thanks for the info. I'm just hacking around with this stuff now and I discovered Context.ConnectionAborted available to my Hub implementation. Is that valid to use instead of this for the meantime for passing down into other code?

[analogrelay]

Yeah, that token will be signalled when the connection is terminated, so it's the best token we've got right now :)

[davidfowl]

Closing this as we have no plans to do this.