[BUG] Microsoft.Azure.WebJobs.Extensions.ServiceBus delay between batches of session-based messages

Library name and version

Microsoft.Azure.WebJobs.Extensions.ServiceBus, 5.3.0

Describe the bug

Didn’t realize v5.x moved here, see info from this other issue in the old repo. https://github.com/Azure/azure-functions-servicebus-extension/issues/180#issue-1163179060

TLDR: A simple ServiceBusTrigger is seeing a delay after processing MaxConcurrentSessions messages that appears related to the TryTimeout setting.

Expected behavior

To keep processing messages until there are no more messages in the queue.

Actual behavior

Process 8 messages, delay of 1 minute, process 8 messages, repeat until queue is empty.

This is actually causing the Azure scaler to scale-out the function app to max nodes as the queue does not get emptied fast enough.

Reproduction Steps

Function:

using System.Threading.Tasks;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.ServiceBus;
using Microsoft.Extensions.Options;

namespace FunctionApp1
{
    public class Function1
    {
        [FunctionName("Function1")]
        public async Task RunAsync([ServiceBusTrigger("queue-name", IsSessionsEnabled = true)] string json)
        {
        }
    }
}

host.json

{
  "version": "2.0",
  "logging": {
    "logLevel": {
      "default": "Debug"
    },
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true,
        "excludedTypes": "Request"
      }
    }
  }
}

local.settings.json

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "AzureWebJobsServiceBus": "Endpoint=sb://.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=",
    "FUNCTIONS_WORKER_RUNTIME": "dotnet"
  }
}

Environment

This happens locally and appears to be happening when deployed in Azure. Also noticed similar behavior on dotnet-isolated worker with similar code/setup except that it would process 2000 messages and then wait because the MaxConcurrentSessions value is 2000 instead of 8 as it was in the in-process worker.

[vipinlalvs]

@smokedlinq, did you get any workaround/fix on this?. We are also facing similar issue.

[smokedlinq]

Yes I lowered the SessionIdleTimeout setting to 1 second. The session will wait for more messages before giving up. The default is 1 minute.