Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/Azure/Azure-Functions/issues/1915 below:

Enforce default and max. dynamic sku function timeout for Linux consumption · Issue #1915 · Azure/Azure-Functions · GitHub

Discussion for this proposal can be found here: #1919

Proposal to make function timeout consistent across Windows and Linux consumption skus.

There will be 2 changes

1. Currently Windows consumption uses a default function time out of 5 min. On Linux consumption the default timeout is 30 min.

https://github.com/Azure/azure-functions-host/blob/dev/src/WebJobs.Script/Config/ScriptJobHostOptionsSetup.cs#L82

1. On Windows consumption max function timeout is 10 min and on Linux consumption the limit is not enforced.

https://github.com/Azure/azure-functions-host/blob/916c255778588951371ffc0da74b7a2c3f1ec2b8/src/WebJobs.Script/Config/ScriptJobHostOptionsSetup.cs#L100

What is the motivation for the change?

The current state was an oversight and not intentional.
Consistency across different skus allowing easier migration.
Allows rest of the platform components to use the same rules when scaling in/out instances.

How many customers (roughly) would be impacted by this break? If not known, how can we figure it out? This may require host changes to gather metrics.

Enforcing the max timeout limit of 10 min will impact ~5% of apps (based on function.invoke.latency metric). This is assuming customers update their host.json to specify 10 min as the functiontimeout limit.
If apps are not updated to explicitly specify the timeout limit 8% of apps will be impacted.

We'd like to enable compat-mode support for every breaking change. This may not be feasible in reality, but each proposal should include a plan to switch back to the previous behavior with a feature flag. This requirement will be evaluated on a case-by-case basis.

Since this is a bug fix, the break is intentional so not considering any compat-mode flags.

Were any alternatives discussed? Is there any way to do this without a break?

No.

Can we detect that a customer is using this when they upgrade from v3? Is there a specific error that can be thrown with a link to migration guidance?

Yes.
Apps that will see potential impact upon moving to v4 can be identified by tracking function.invoke.latency metric (>10 min)
After migration the failures can be tracked using Microsoft.Azure.WebJobs.Host.FunctionTimeoutException
The timeouts are documented at https://docs.microsoft.com/en-us/azure/azure-functions/functions-host-json#functiontimeout, so yes a link can be provided.

Will there be any incidents-per-day impact? Who will be the support contact? Does support need to be notified of this change? (SPOT)

Yes.
Functions team.
Yes.

Documentation impact

None

What components does this change impact? Examples of areas (this list may not be exhaustive):
- Host
- Tooling (VS, VS Code, CLI)
- Portal UX
- Azure CLI

Host

Does the change have any performance impact? There may need to be some implementation complete before this can be measured.

No

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