Azure / Azure/azure-functions-host
Host Initialized state never set
- Dominant language
- C#
- Stars
- 2k
- Forks
- 482
- Avg merge
- 2d 12h
- Merged PRs (30d)
- 38
Description
In v1 we have a HostInitialized ScriptHostState that is set when all functions for the host are fully indexed but before listeners are started. This allows direct invocations to happen in parallel with listener startup. Listener startup can take a while, so it's beneficial to not block direct invocations (e.g. portal invocations, Http, WebHooks).
However, it appears that in the move to v2 some of this logic was not carried forward. E.g. the CanInvoke helper [here](https://github.com/Azure/azure-functions-host/blob/ec8984ef1529c95aa5638c5c942eb55077d95b4b/src/WebJobs.Script/Host/ScriptHostManagerExtensions.cs#L17) checks for HostInitialized, but nowhere in the code is that ever set. In v1 it was set [here](https://github.com/Azure/azure-functions-host/blob/2942e616bdfadf3a41760505b480d5533a3348c4/src/WebJobs.Script/Host/ScriptHostManager.cs#L449).
We should add this back, to reduce the delays imposed by this. See related v1 issue https://github.com/Azure/azure-webjobs-sdk/pull/2104. We should take all these fixes together - merging this v1 fix to v2.
Contributor guide
Research direction
Start with ScriptHostManagerExtensions.cs and its CanInvoke helper, then compare the v2 startup flow in ScriptHostManager.cs with the linked v1 implementation. Trace when functions are indexed and listeners start; the work is done when HostInitialized is set at the corresponding point so direct invocations can proceed during listener startup.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 48/100