.NET 8 HttpContext is null when it is not in .NET 6 about azure-functions-dotnet-worker HOT 11 OPEN

We found a workaround for this that may work for others. It involves a very minimal custom middleware component:

public class HttpContextAccessorMiddleware(IHttpContextAccessor httpContextAccessor) : IFunctionsWorkerMiddleware
{
    public async Task Invoke(FunctionContext context, FunctionExecutionDelegate next)
    {
        httpContextAccessor.HttpContext = context.GetHttpContext();
        await next(context);
    }
}

Then wire it up in Program.cs

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication(builder =>
    {
        builder.UseMiddleware<HttpContextAccessorMiddleware>();
    })

This should allow you to inject IHttpContextAccessor as you did prior to moving to isolated. I have only confirmed this on .NET 6, but I assume it will work in 8 as well.

from azure-functions-dotnet-worker.

We are using the above middleware pattern in our .net8 out-of-process functions. However it does not appear to be 100% parity with in-proc.

I'm doing the following to get access to Application Insights request telemetry so that we can insert custom properties. HttpContext is available but this returns NULL still.

var telemetry = _httpContextAccessor.HttpContext?.Features.Get<RequestTelemetry>();

I'm aware that this isn't quite on point; just be aware that the above middleware suggestion may not solve everything.

from azure-functions-dotnet-worker.

Yes this works with the middleware in .NET 8

from azure-functions-dotnet-worker.

Came across same issue, after migrating from .net 6 to .net 8 the IHttpContextAccessor is null when retrieved from context.

from azure-functions-dotnet-worker.

I am also facing the same issue when I am trying to upgrade my projects from Net6 to Net8.
I can initialize HttpContextAccessor by using services.AddHttpContextAccessor()
But then HttpContextAccessor.HttpContext is null.

Any idea when this issue is going to be fixed?

Note: We didn't need to initialize HttpContextAccessor in Net6. It is automatically getting initialized during each function endpoint call.

from azure-functions-dotnet-worker.

Same issue like @Tech-Sohail just described, here also :(

As far as I understand, the problem is that I am not using an HTTPTrigger. If you are using an Event trigger or a Timer trigger, you won't have a context... IHttpContextAccessor and HttpContext are not available in these cases. It seems the idea is that if you have information in the context, that info should be in the event itself.

from azure-functions-dotnet-worker.

Same issue like @Tech-Sohail just described, here also :(

As far as I understand, the problem is that I am not using an HTTPTrigger. If you are using an Event trigger or a Timer trigger, you won't have a context... IHttpContextAccessor and HttpContext are not available in these cases. It seems the idea is that if you have information in the context, that info should be in the event itself.

No, this issue is purely about the lack of HTTP Context on a http trigger, I would never expect to have a http trigger on event or Timer, in .NET 6 we uses Queue triggers extensively but there is no http context in those circumstances and that is expected behaviour.

Still waiting on anything from MS on this, so far seems to just have been added and removed from various labels, I rechecked the latest nuget packages recently (see sample project) and its still ongoing to latest releases

from azure-functions-dotnet-worker.

@MarkMilfordMe I don't think that this is a .NET 8 vs .NET 6 issue. It appears to be an in-process vs out-of-process function issue. Your .NET 6 demo project is in-process and your .NET 8 demo project is out-of-process. If you were to change your .NET 6 project to out-of-process, I suspect you would see the same behavior. We are currently seeing the same thing when doing a straight in-process to out-of-process migration in a .NET 6 function application.

from azure-functions-dotnet-worker.

@MarkMilfordMe I don't think that this is a .NET 8 vs .NET 6 issue. It appears to be an in-process vs out-of-process function issue. Your .NET 6 demo project is in-process and your .NET 8 demo project is out-of-process. If you were to change your .NET 6 project to out-of-process, I suspect you would see the same behavior. We are currently seeing the same thing when doing a straight in-process to out-of-process migration in a .NET 6 function application.

Thanks, I'll try that, guess still means we can't update to .NET 8 though, as .NET 8 doesn't support in-process to my knowledge.

from azure-functions-dotnet-worker.

@MarkMilfordMe I don't think that this is a .NET 8 vs .NET 6 issue. It appears to be an in-process vs out-of-process function issue. Your .NET 6 demo project is in-process and your .NET 8 demo project is out-of-process. If you were to change your .NET 6 project to out-of-process, I suspect you would see the same behavior. We are currently seeing the same thing when doing a straight in-process to out-of-process migration in a .NET 6 function application.

Thanks, I'll try that, guess still means we can't update to .NET 8 though, as .NET 8 doesn't support in-process to my knowledge.

You are correct. .NET 8 is not supported for in-proc functions yet. There is a tracking issue that indicates that support for Windows functions should be rolling out sometime this month (June).

from azure-functions-dotnet-worker.

@MarkMilfordMe I don't think that this is a .NET 8 vs .NET 6 issue. It appears to be an in-process vs out-of-process function issue. Your .NET 6 demo project is in-process and your .NET 8 demo project is out-of-process. If you were to change your .NET 6 project to out-of-process, I suspect you would see the same behavior. We are currently seeing the same thing when doing a straight in-process to out-of-process migration in a .NET 6 function application.

Thanks, I'll try that, guess still means we can't update to .NET 8 though, as .NET 8 doesn't support in-process to my knowledge.

You are correct. .NET 8 is not supported for in-proc functions yet. There is a tracking issue that indicates that support for Windows functions should be rolling out sometime this month (June).

So just did a quick example (added to original repo) and yes it fails on .net 6 out of proc. Will cross fingers that In-Proc .NET 8 rolls out in plenty of time for us to transistion before november when .net 6 is out of support! Will subscribe to the issue you mentioned. Thanks

from azure-functions-dotnet-worker.