Support for HttpContext.RequestAborted in the HttpTrigger cancellation token

[CasperWSchmidt]

What problem would the feature you're requesting solve? Please describe.

Using Http triggers in Azure Functions is a common use case. Having longer running functions is also quite normal. Therefore I'm actually quite surprised that cancelling a request (fx. in Postman) affect the function running. IMHO that is what developers would expect (at least it's what I did, and what the author did here)

Describe the solution you'd like

Something like what's described here - when the client cancels the http request the Azure Function should be notified through the cancellation token by default

Describe alternatives you've considered

Manually handling the linking of the host cancellation token and HttpContext.RequestAborted as described here

Additional context

None

[miqm]

Subscribing to topic - this is also a problem with python worker - cancelled http requests can wait for a quite long time and execute long after client drops the connection which can lead ineffectiveness in utilising resources.

[esimkowitz]

It is super exciting to see this issue being addressed and getting this regression closed! Do you have an ETA for when this will get rolled out to the SDK?

I am also throwing my support behind the idea of linking this to the existing FunctionContext.CancellationToken (from what I gathered from the draft PR, that is the current proposal?). That is the most intuitive approach from a developer standpoint, especially since I imagine a lot of developers already assume that is how this works (I know I did until today!).

[liliankasem]

It is super exciting to see this issue being addressed and getting this regression closed! Do you have an ETA for when this will get rolled out to the SDK?

I am also throwing my support behind the idea of linking this to the existing FunctionContext.CancellationToken (from what I gathered from the draft PR, that is the current proposal?). That is the most intuitive approach from a developer standpoint, especially since I imagine a lot of developers already assume that is how this works (I know I did until today!).

I think you're commenting about CancellationToken support in the dotnet worker? This is already supported today, that feature went out last year (code). You should be able to bind to the CancellationToken directly or use it via FunctionContext.

The focus of this issue/PR is to also take into account the the RequestAborted cancellation token with the host/platform CancellationToken that we use/handle today. I wouldn't consider it a regression as support for RequestAborted did not exist with in-proc dotnet either.

For RequestAborted support, ETA would be maybe some time next month. PR needs to go through review & testing and when that is merged it could take 3-4 weeks for the release to roll out.

[esimkowitz]

Got it, that clears things up thank you! Very much looking forward to this going in!