azureazure-functionsazure-webjobsazure-webjobs-triggered

Supported bindings for Singleton scopeId on HTTP Trigger Azure Function


I am unclear on how the scopeId parameter of the SingletonAttribute works. Specifically does the scopeId parameter work for HTTP Trigger Azure Functions when you bind it to a route parameter? How does the binding work? What variables/values can I bind to?

For example:

[Singleton("{input}", Mode = SingletonMode.Listener)]
public async Task<IActionResult> Run([HttpTrigger(AuthorizationLevel.Anonymous, "post", Route = "v1/{input:length(1,30)}")] Microsoft.AspNetCore.Http.HttpRequest req, string input, ILogger log) {
    return new OkObjectResult(input + " world");
}

A HTTP POST request to this function with the URI 'v1/hello' would return: "Hello world".

But would the Singleton attribute work such that all requests to 'v1/hello' would run serially whereas two simultaneous requests with one to 'v1/first' and the other to 'v1/second' would run in parallel?

I see from this answer that for Service Bus Triggers you can bind to properties within the Message object directly.
Also in the documentation there is an example of a Queue Trigger Function with scopeId binding to a property in the WorkItem object.
It's unclear what's supported for HTTP Trigger Functions.


Solution

  • I got a reply from Microsoft on GitHub: https://github.com/MicrosoftDocs/azure-docs/issues/69011#issuecomment-771922910

    "Binding expressions for Singleton have the same behavior as those for general input/output bindings. That is, any binding data from the trigger is available for reference.

    In the case of HttpTrigger, that includes any POCO members if you’re binding to a POCO type, as well as any route parameters. In regards to your code, SingletonMode.Listener is not what you want for your requirement. If you're just trying to serialize individual invocations of the function then you should use the default mode, i.e. [Singleton(“{input}”)].

    To answer your question – yes, this would serialize all invocations of v1/hello, allowing v1/first and v1/second to run concurrently."