Azure / Azure/azure-functions-host

Host Initialized state never set

Open
#4,023 0 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.