For out-of-process language workers, the specialization process (environment reload request) has a 30-second timeout. If a customer's function app takes longer than 30 seconds to start, the timeout will trigger, resulting in an exception like the one below in the logs
System.AggregateException : One or more errors occurred. (The operation has timed out.) ---> The operation has timed out. ---> (Inner Exception #0) System.TimeoutException : The operation has timed out. at Microsoft.Azure.WebJobs.Script.Grpc.GrpcWorkerChannel.PendingItem.OnTimeout() at /src/azure-functions-host/src/WebJobs.Script.Grpc/Channel/GrpcWorkerChannel.cs : 1799 at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at async Microsoft.Azure.WebJobs.Script.Workers.Rpc.WebHostRpcWorkerChannelManager.SpecializeAsync() at /src/azure-functions-host/src/WebJobs.Script/Workers/Rpc/WebHostRpcWorkerChannelManager.cs : 134 at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at async Microsoft.Azure.WebJobs.Script.WebHost.StandbyManager.SpecializeHostCoreAsync() at /src/azure-functions-host/src/WebJobs.Script.WebHost/Standby/StandbyManager.cs : 117<---
Currently, there is no way for customers to configure this timeout. A solution is needed to allow customization of this value. Additionally, the exception message should be improved for clarity, indicating that the specialization has failed if the app takes more than 30 seconds to start.
For now, .NET Isolated customers can work around this issue by disabling the specialization code path. This can be done by setting the WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED app setting to 0
cjaliaga, nzthiago and Aghyad85
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4