7

Does anyone know what this error represents? We are currently using Azure Service Bus, and trying to understand its meaning.

Microsoft.Azure.WebJobs.Script.HostDisposedException: The host is disposed and cannot be used. Disposed object: 'Microsoft.Azure.WebJobs.Script.WebHost.DependencyInjection.ScopedResolver'; Found IListener in stack trace: 'Microsoft.Azure.WebJobs.ServiceBus.Listeners.ServiceBusListener

mattsmith5
  • 540
  • 4
  • 29
  • 67
  • 1
    Looks like they don't know the root cause yet. I would go ahead and open a GitHub Issue and provide the full stack trace to help them collect the information they need to find the cause. https://github.com/Azure/azure-functions-host/pull/6758 – Adam Vincent Jul 09 '21 at 03:21
  • Are you using ServiceBus triggered Azure Functions? – Prasad Bhokare Jul 09 '21 at 22:15
  • yes, @PrasadBhokare service bus with Azure functions – mattsmith5 Jul 10 '21 at 00:08

2 Answers2

8

Ok coming back at it again. I upgraded our azure function from v3 to v4 as part of .NET 6 upgrade and suddenly starting getting similar exceptions. Even the function was getting triggered at random times.

Container is disposed and should not be used: Container is disposed.You may include Dispose stack-trace into the message via:container.With(rules => rules.WithCaptureContainerDisposeStackTrace())

The host is disposed and cannot be used. Disposed object: 'Microsoft.Azure.WebJobs.Script.WebHost.DependencyInjection.ScopedResolver' Container is disposed and should not be used: Container is disposed. You may include Dispose stack-trace into the message via: container.With(rules => rules.WithCaptureContainerDisposeStackTrace())

enter image description here

Adding the configuration setting AzureFunctionsWebHost__hostId solved 90% of these errors. You can read more here. Reason is because our function name was longer than 32 chars.

But for the remaining 10% of the cases, I had to debug the framework code because it wasn't telling me what object it was trying to resolve and failing. Luckily during call-stack unwinding process of the exception, I was able to see the local variables and saw the object. I had to then change the DI code in StartUp/Program class. There were some singleton objects that we newed up and resolved using syntax like x => x.GetService but I replaced it with newed up object instead. There is a breaking change in V4 on how the DI scopes are resolved within the JobHost. See here for more info.

Hopefully this would help others.

Varun Sharma
  • 2,591
  • 8
  • 45
  • 63
2

Looks you are also facing this exact known issue that is still open in GitHub https://github.com/Azure/azure-functions-host/issues/5240

As described by "petterek" there you can try the workaround by doing

using (var scope = scopeFactory.CreateScope())

Alternatively until this is resolved you can increase the retry count, this is our temporary fix making the message idempotent and increasing the retry count.

Ricky Gummadi
  • 4,559
  • 2
  • 41
  • 67
  • 1
    Haha I had the same issue lol. At least we got to meet here :D – Varun Sharma Oct 06 '21 at 04:46
  • 1
    Haha nice to see you @VarunSharma hope you are keeping well. Keep in mind that if your are using an Azure function that is processing this message retry count wont help that much because the retry happens immediately. There is a new updated 5.xxx nuget package extensions for the functions that offer the exponential reties – Ricky Gummadi Oct 07 '21 at 03:40
  • Can someone confirm if this workaround is still necessary to avoid the problem? – Joe Eng Dec 16 '22 at 18:55
  • @JoeyEng I believe this is no longer an issue – Ricky Gummadi Dec 16 '22 at 22:35