Couple of functions not executing after upgrade

Question

Couple of functions not executing after upgrade

Jinugu, Manasa 0

after upgrading from inprocess to Isolated couple of functions not executing throwing error Failed indexing and will be disabled

Praveen Kumar Gudipudi 2,295 Reputation points Microsoft External Staff Moderator

2025-11-26T07:44:42.0666667+00:00

Hello Jinugu, Manasa,

The isolated worker model fails indexing for different reasons so please share me the Log Stream Error.

Azure Portal → Function App → Log stream.

Error seems like:

"""Error indexing method ...

System.Private.CoreLib: Exception...

Binding initialization failed...

Could not load type..."""

Or if you have any Application Insights traces please share those as well to proceed further.
Praveen Kumar Gudipudi 2,295 Reputation points Microsoft External Staff Moderator

2025-11-28T04:35:54.8333333+00:00

Hello Jinugu, Manasa,

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.

2 answers

Your answer

Praveen Kumar Gudipudi 2,295 Reputation points Microsoft External Staff Moderator

2025-11-26T07:44:42.0666667+00:00

Hello Jinugu, Manasa,

The isolated worker model fails indexing for different reasons so please share me the Log Stream Error.

Azure Portal → Function App → Log stream.

Error seems like:

"""Error indexing method ...

System.Private.CoreLib: Exception...

Binding initialization failed...

Could not load type..."""

Or if you have any Application Insights traces please share those as well to proceed further.
Praveen Kumar Gudipudi 2,295 Reputation points Microsoft External Staff Moderator

2025-11-28T04:35:54.8333333+00:00

Hello Jinugu, Manasa,

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.

Answer 1

"Failed indexing and will be disabled" is only the summary line. The Functions host logs the actual reason just before it, in a line that starts with Error indexing method. That line tells you exactly what to fix.

I reproduced this with a .NET 9 isolated app containing one healthy HTTP function and two broken timer functions. The healthy function kept working, and the host logged this for the other two:

Microsoft.Azure.WebJobs.Host: Error indexing method 'Functions.TimerFromMissingSetting'. Microsoft.Azure.WebJobs.Host: '%NightlySchedule%' does not resolve to a value.
Function 'Functions.TimerFromMissingSetting' failed indexing and will be disabled.

Microsoft.Azure.WebJobs.Host: Error indexing method 'Functions.TimerBadCron'. Microsoft.Azure.WebJobs.Extensions: The schedule expression '0 0 25 * * *' was not recognized as a valid cron expression or timespan string.
Function 'Functions.TimerBadCron' failed indexing and will be disabled.

How to find the real error

Locally: run func start and look for the line just before "failed indexing".
In Azure: open the Function App, go to Log stream, restart the app and watch the startup output. Or query Application Insights:

traces
| where timestamp > ago(1d)
| where message has "Error indexing method" or message has "failed indexing"
| project timestamp, message
| order by timestamp desc

The most common cause after an upgrade: a missing app setting

The first error above is easy to hit when migrating. A binding refers to an app setting with %...%, such as a timer schedule [TimerTrigger("%NightlySchedule%")] or a queue name "%QueueName%". If that setting doesn't exist where the upgraded app runs, the function can't be indexed and is disabled. Check that every setting the old app used exists:

in the Function App's Environment variables in Azure,
in every deployment slot you swap through, if you use slots,
and in local.settings.json when running locally.

Fix the setting or value named in the error, restart the app, and the function should index normally.

If the error names something else, such as a binding type or connection, include the full "Error indexing method" line in a reply here and I can take a look."Failed indexing and will be disabled" is only the summary line. The Functions host logs the actual reason just before it, in a line that starts with Error indexing method. That line tells you exactly what to fix.

I reproduced this with a .NET 9 isolated app containing one healthy HTTP function and two broken timer functions. The healthy function kept working, and the host logged this for the other two:

Microsoft.Azure.WebJobs.Host: Error indexing method 'Functions.TimerFromMissingSetting'. Microsoft.Azure.WebJobs.Host: '%NightlySchedule%' does not resolve to a value.
Function 'Functions.TimerFromMissingSetting' failed indexing and will be disabled.

Microsoft.Azure.WebJobs.Host: Error indexing method 'Functions.TimerBadCron'. Microsoft.Azure.WebJobs.Extensions: The schedule expression '0 0 25 * * *' was not recognized as a valid cron expression or timespan string.
Function 'Functions.TimerBadCron' failed indexing and will be disabled.

How to find the real error

Locally: run func start and look for the line just before "failed indexing".
In Azure: open the Function App, go to Log stream, restart the app and watch the startup output. Or query Application Insights:

traces
| where timestamp > ago(1d)
| where message has "Error indexing method" or message has "failed indexing"
| project timestamp, message
| order by timestamp desc

The most common cause after an upgrade: a missing app setting

The first error above is easy to hit when migrating. A binding refers to an app setting with %...%, such as a timer schedule [TimerTrigger("%NightlySchedule%")] or a queue name "%QueueName%". If that setting doesn't exist where the upgraded app runs, the function can't be indexed and is disabled. Check that every setting the old app used exists:

in the Function App's Environment variables in Azure,
in every deployment slot you swap through, if you use slots,
and in local.settings.json when running locally.

Fix the setting or value named in the error, restart the app, and the function should index normally.

If the error names something else, such as a binding type or connection, include the full "Error indexing method" line in a reply here and I can take a look.

Answer 2

When upgrading from the in-process model to the isolated worker model in Azure Functions, it's important to ensure that all configurations and dependencies are correctly updated. The error "Failed indexing and will be disabled" typically indicates that there are issues with the function's bindings or the configuration settings not aligning with the isolated model requirements.

Here are some steps to troubleshoot and resolve the issue:

Check Function Bindings: Ensure that all binding references in your functions have been updated to their isolated model counterparts. For example, if you were using Microsoft.Azure.WebJobs.Extensions.DurableTask, you need to replace it with Microsoft.Azure.Functions.Worker.Extensions.DurableTask.
Review Configuration Settings: Confirm that the FUNCTIONS_WORKER_RUNTIME setting is set to dotnet-isolated in your application settings. This setting should not be marked as a slot setting if you are using deployment slots.
Deployment Slots: If you are using deployment slots, make sure that the staging slot is configured correctly and that you have tested the functions there before swapping to production.
Logs and Diagnostics: Check the logs for any specific error messages that can provide more context on why the functions are failing. This can help identify if there are any missing dependencies or misconfigurations.
Update Extensions: Ensure that all extensions used in your functions are updated to the latest versions compatible with the isolated worker model.

If the issue persists, consider rolling back to the previous version temporarily while you investigate further or consult the Azure Functions documentation for additional troubleshooting guidance.