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
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())
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.
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.