You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The SyncTriggers admin operation is a WebHost level API that currently doesn't require a running ScriptHost (see API here - it's not marked [RequiresRunningHost]). Historically when we only had file based function.json indexing that hasn't been a problem, because the metadata provider didn't requires a running host - it just indexed function directories.
With the recent addition of worker indexing, we need to verify that those assumptions still hold, and ensure that the SyncTriggers behavior is correct in cases where the worker can't start. FunctionsSyncManager uses the WebHost metadata provider here to get metadata. If this metadata provider can't return reliable information (e.g. worker can't start) it needs to hard fail - not return empty, since the latter could result in oscillating sync operations in the case of transient failures.
Similarly, Functions also supports custom IFunctionProvider implementations that can be provided by extensions when they're registered. Metadata from these providers requires a running host, since they're only added when the inner host has started.
In summary, we need to spend time exploring these worker indexing scenarios to see if things are behaving the way we expect. However, I do think we should just mark the operation RequiresRunningHost.
The text was updated successfully, but these errors were encountered:
The SyncTriggers admin operation is a WebHost level API that currently doesn't require a running ScriptHost (see API here - it's not marked
[RequiresRunningHost]
). Historically when we only had file based function.json indexing that hasn't been a problem, because the metadata provider didn't requires a running host - it just indexed function directories.With the recent addition of worker indexing, we need to verify that those assumptions still hold, and ensure that the SyncTriggers behavior is correct in cases where the worker can't start. FunctionsSyncManager uses the WebHost metadata provider here to get metadata. If this metadata provider can't return reliable information (e.g. worker can't start) it needs to hard fail - not return empty, since the latter could result in oscillating sync operations in the case of transient failures.
Similarly, Functions also supports custom IFunctionProvider implementations that can be provided by extensions when they're registered. Metadata from these providers requires a running host, since they're only added when the inner host has started.
In summary, we need to spend time exploring these worker indexing scenarios to see if things are behaving the way we expect. However, I do think we should just mark the operation RequiresRunningHost.
The text was updated successfully, but these errors were encountered: