Alguien sabe que representa este error? Actualmente estamos usando Azure Service Bus y estamos tratando de entender su significado.
Microsoft.Azure.WebJobs.Script.HostDisposedException: el host se desecha y no se puede usar. Objeto eliminado: 'Microsoft.Azure.WebJobs.Script.WebHost.DependencyInjection.ScopedResolver'; Encontrado IListener en el seguimiento de la pila: 'Microsoft.Azure.WebJobs.ServiceBus.Listeners.ServiceBusListener
Parece que también enfrenta este problema conocido exacto que todavía está abierto en GitHub https://github.com/Azure/azure-functions-host/issues/5240
Como se describe en "petterek", puede probar la solución alternativa haciendo
using (var scope = scopeFactory.CreateScope())Alternativamente, hasta que esto se resuelva, puede aumentar el número de reintentos, esta es nuestra solución temporal que hace que el mensaje sea idempotente y aumente el número de reintentos.
Ok volviendo a eso de nuevo. Actualicé nuestra función Azure de v3 a v4 como parte de la actualización de .NET 6 y, de repente, comencé a obtener excepciones similares. Incluso la función se activaba en momentos aleatorios.
El contenedor se eliminó y no se debe usar: El contenedor se eliminó. Puede incluir Dispose stack-trace en el mensaje a través de:container.With(rules => rules.WithCaptureContainerDisposeStackTrace())
El host se desecha y no se puede utilizar. Objeto desechado: 'Microsoft.Azure.WebJobs.Script.WebHost.DependencyInjection.ScopedResolver' El contenedor está desechado y no debe usarse: El contenedor está desechado. Puede incluir Dispose stack-trace en el mensaje a través de: container.With(rules => rules.WithCaptureContainerDisposeStackTrace())
Agregar el parámetro de configuración AzureFunctionsWebHost__hostId resolvió el 90 % de estos errores. Puedes leer más aquí . El motivo es que el nombre de nuestra función tenía más de 32 caracteres.
Pero para el 10 % restante de los casos, tuve que depurar el código del marco porque no me decía qué objeto estaba tratando de resolver y fallaba. Afortunadamente, durante el proceso de desenrollado de la excepción de la pila de llamadas, pude ver las variables locales y vi el objeto. Luego tuve que cambiar el código DI en la clase StartUp/Program. Hubo algunos objetos singleton que actualizamos y resolvimos usando una sintaxis como x => x.GetService, pero en su lugar lo reemplacé con un objeto actualizado. Hay un cambio importante en V4 sobre cómo se resuelven los ámbitos DI dentro de JobHost. Vea aquí para más información.
Esperemos que esto ayude a otros.