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
If functions runtime cannot fully specialize it can get stuck with the placeholder 'WarmUp' function
Sample pod - in the below case the specialization succeeded once and loaded the actual customer functions. Functions runtime restarted and then re-specialization failed (due to lack of container start context mount non-availability in this case) and the pod was left with 'Warmup' Function
Note1 - The exact thing to address is - we should never return WarmUp Function when customer lists functions (i.e portal shouldn't display 'Warmup' function)
Note2 - In the below pod the failure was during re-specialization but this can happen during initial specialization as well
Note3 - The exact reason here is a different bug (lack of context mount path) but even if we fix that, there might be other reasons for failures. so this workitem is to explore options to see if we can
a) dont switch to specialized mode if specialization is 'fully complete'
b) if we cannot do a, can we revert back to placeholder mode to prevent the instance from causing confusion
|whereSummarycontains"Found the following functions:"orSummarycontains"will attempt"
PreciseTimeStamp | Summary
-- | --
2024-05-14 22:47:28.0664600 | Found the following functions: Host.Functions.WarmUp
2024-05-14 22:47:31.0712436 | Found the following functions: Host.Functions.WarmUp
2024-05-15 00:56:52.1614246 | Found the following functions: Host.Functions.HelloWorld Host.Functions.HtmlParser Host.Functions.LoaderIO
2024-05-15 01:03:05.1607510 | WebHost has shut down. Will attempt restart.
2024-05-15 01:03:30.1589962 | Found the following functions: Host.Functions.WarmUp
If functions runtime cannot fully specialize it can get stuck with the placeholder 'WarmUp' function
Sample pod - in the below case the specialization succeeded once and loaded the actual customer functions. Functions runtime restarted and then re-specialization failed (due to lack of container start context mount non-availability in this case) and the pod was left with 'Warmup' Function
Note1 - The exact thing to address is - we should never return WarmUp Function when customer lists functions (i.e portal shouldn't display 'Warmup' function)
Note2 - In the below pod the failure was during re-specialization but this can happen during initial specialization as well
Note3 - The exact reason here is a different bug (lack of context mount path) but even if we fix that, there might be other reasons for failures. so this workitem is to explore options to see if we can
a) dont switch to specialized mode if specialization is 'fully complete'
b) if we cannot do a, can we revert back to placeholder mode to prevent the instance from causing confusion
Execute: [Web] [Desktop] [Web (Lens)] [Desktop (SAW)] https://wawseus.kusto.windows.net/wawsprod
FunctionsLogs
| where PreciseTimeStamp >= datetime(2024-05-14T15:57:00.0000000Z) - 3h
| where PreciseTimeStamp <= datetime(2024-05-15T01:04:00.0000000Z) + 3h
| where SourceNamespace == "FunctionsLegion"
| extend PodName = RoleInstance
| where PodName == "3ea83371-4d4d-4d4e-bf18-ccf6aefc9798"
| project PreciseTimeStamp, Summary
| order by PreciseTimeStamp asc
| where Summary contains "Found the following functions:" or Summary contains "will attempt"
If functions runtime cannot fully specialize it can get stuck with the placeholder 'WarmUp' function
Sample pod - in the below case the specialization succeeded once and loaded the actual customer functions. Functions runtime restarted and then re-specialization failed (due to lack of container start context mount non-availability in this case) and the pod was left with 'Warmup' Function
Note1 - The exact thing to address is - we should never return WarmUp Function when customer lists functions (i.e portal shouldn't display 'Warmup' function)
Note2 - In the below pod the failure was during re-specialization but this can happen during initial specialization as well
Note3 - The exact reason here is a different bug (lack of context mount path) but even if we fix that, there might be other reasons for failures. so this workitem is to explore options to see if we can
a) dont switch to specialized mode if specialization is 'fully complete'
b) if we cannot do a, can we revert back to placeholder mode to prevent the instance from causing confusion
Execute: [Web] [Desktop] [Web (Lens)] [Desktop (SAW)] https://wawseus.kusto.windows.net/wawsprod
FunctionsLogs
| where PreciseTimeStamp >= datetime(2024-05-14T15:57:00.0000000Z) - 3h
| where PreciseTimeStamp <= datetime(2024-05-15T01:04:00.0000000Z) + 3h
| where SourceNamespace == "FunctionsLegion"
| extend PodName = RoleInstance
| where PodName == "3ea83371-4d4d-4d4e-bf18-ccf6aefc9798"
| project PreciseTimeStamp, Summary
| order by PreciseTimeStamp asc
| where Summary contains "Found the following functions:" or Summary contains "will attempt"
PreciseTimeStamp
Summary
2024-05-14 22:47:28.0664600
Found the following functions: Host.Functions.WarmUp
2024-05-14 22:47:31.0712436
Found the following functions: Host.Functions.WarmUp
2024-05-15 00:56:52.1614246
Found the following functions: Host.Functions.HelloWorld Host.Functions.HtmlParser Host.Functions.LoaderIO
2024-05-15 01:03:05.1607510
WebHost has shut down. Will attempt restart.
2024-05-15 01:03:30.1589962
Found the following functions: Host.Functions.WarmUp
The text was updated successfully, but these errors were encountered: