FunctionInputConverterException: Azure Functions in .NET dotnet-isolated process get a FunctionContext rather than an ExecutionContext

When you upgrade an Azure Function to .NET 8 dotnet-isolated model, the Webjobs namespace goes away, and gets replaced by the Microsoft.Azure.Functions.Worker namespace.

In the Webjobs namespace, there is a ExceutionContext that you can inject into your function. Here's a writeup on that from 2020: Quick tip: using ExecutionContext in Azure Functions.

This is no longer available in the Azure.Functions.Worker namespace. By the docs at learn.microsoft.com:

The logger can also be obtained from a FunctionContext object passed to your function.

So, you can replace any usage of ExecutionContext with FunctionContext. But here's the gotcha: there also exists a System.Threading.ExecutionContext class. Any C# that uses the System.Threading.Task class involved with the await / async pattern is likely to be using this namespace. The result is that any references to an ExcecutionContext will happily pass the compiler even with the Webjobs packages uninstalled, and that may lead to cryptic runtime errors.

So when you migrate to dotnet-isolated functions, make sure you aren't inadvertently referencing a System.Threading.Execution context in your Func signature, or you'll get hit with the Microsoft.Azure.Functions.Worker.FunctionInputConverterException.