Skip to content
This repository has been archived by the owner on Jul 19, 2024. It is now read-only.

Make message host level configurations configurable per function #138

Closed
apranaseth opened this issue Mar 8, 2021 · 1 comment · Fixed by #155
Closed

Make message host level configurations configurable per function #138

apranaseth opened this issue Mar 8, 2021 · 1 comment · Fixed by #155
Assignees

Comments

@apranaseth
Copy link
Member

apranaseth commented Mar 8, 2021

In hosts.json, under message options below configurations can be set. With this feature, the user will be able to set them per function as well. This way within the same job host (WebJobs or Functions), different functions could be defined with flavors for autocomplete or controlling the complete on its own in the function code.

"messageHandlerOptions": {
"autoComplete": true,
"maxConcurrentCalls": 32,
"maxAutoRenewDuration": "00:05:00"
},

@mathewc
Copy link
Member

mathewc commented Mar 8, 2021

The work here would be to identify the set of primitive type config options from MessageHandlerOptions that we'd need to promote to ServiceBusTriggerAttribute (e.g. AutoComplete, MaxAutoRenewDuration, MaxConcurrentCalls), since you can't use non-constant types in attributes like this:

public static async Task ProcessMessage(
    [ServiceBusTrigger("myqueue", Connection = "ServiceBusConnection", 
    MessageHandlerOptions = new MessageHandlerOptions { AutoComplete = false })] 
    string myQueueItem,
    Int32 deliveryCount,
    DateTime enqueuedTimeUtc,
    string messageId,
    ILogger log)

So we'd have to have:

public static async Task ProcessMessage(
    [ServiceBusTrigger("myqueue", Connection = "ServiceBusConnection"), AutoComplete = false, MaxConcurrentCalls = 16] 
    string myQueueItem,
    Int32 deliveryCount,
    DateTime enqueuedTimeUtc,
    string messageId,
    ILogger log)

Similarly, if we want to also allow this for SessionHandlerOptions, we'd be looking at properties (AutoComplete, MaxAutoRenewDuration, MaxConcurrentSessions, MessageWaitTimeout). Like other option types that are both host/function level (e.g. FunctionTimeout) we'd have to handle these hierarchically and apply the host level first, then function level.

It does mean that we're a middleman then, responsible for copying this config ourselves onto the SB SDK types, so have to maintain this going forward, and expose any new properties they add in the future.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
3 participants