Missing asp.net session, POST request on v6.4


I need asp.net session state, and have session decorator set up (details https://stackoverflow.com/questions/8339584/how-can-i-use-a-standard-asp-net-session-object-within-servicestack-service-impl).

However now after upgrading to 6.4 HttpContext.Current is null on POST requests (same request submitted with GET works ok).

Decorator code runs, but HttpContext.Current is null on global filter on POST requests.

Is there a way to get this to work again?

If you can put a stand-alone repro on GitHub I can take a look.

Looks like System.Web.HttpContext.Current is lost after this line:

perhaps thread issue (?)

After this line (on POST request, not GET)

First breakpoint on line 670 and second breakpoint on line 671, running through nulls System.Web.HttpContext.Current.
However breaking on line 670 and stepping over F10 keeps context, and gives normal results.
Test case with GET did not hit this line.

Reverting to 6.3 gives the HttpContext.Current back and request handler works ok.

The context will go to null under same conditions as above (breakpoints on StreamExtensions.cs lines 670 and 671), however the context is back when request handler executes.

Requests are executed on the browsers worker thread, no additional threads are spawned, the fix will be finding out when to use .ConfigAwait() and when not to but without a repro I wont be able to verify it.

Is there a reason you’re linking to the older version of RestHandler as the latest version calls .ConfigAwait(); on CreateRequestAsync:

If you can provide a repro I can identify and resolve it, otherwise if you’re running a local version of ServiceStack can you try adding or removing .ConfigAwait() to check if it resolves it and let me know and I’ll update accordingly.

Since the older version didn’t use ConfigureAwait() whilst the latest version did, it’s very likely the culprit so I’ve changed it to only use ConfigureAwait in .NET Core in this commit.

This change is available from the latest v6.4.1+ that’s now available on MyGet.

1 Like

Tested on latest MyGet release, test done earlier works now, HttpContext.Current is available, :+1:
(Not sure how I linked, could be different than version on debugger.)

1 Like

I also had the issue where HttpContext.Current is null, and the latest MyGet fixed it. :+1:

1 Like

Well, it’s fixed 99% of the time. Got 1 crash recently where it was null again. Is the fix complete or still a WIP?

Reported fixes are completed, if you provide a new repro we can investigate any others.

Unfortunately this is still not fully fixed. It’s not really easy to get together a repro since it’s so random. Any chance you can have a second look? It’s causing a bit of pain.

It’s not an issue that can be found looking at the source code and would be impossible to find without a repro or at the very least a StackTrace so we know the exact line that either needs to add or remove .ConfigAwait().

The relevant part of the stack trace:

at ServiceStack.Host.ServiceRunner`1.d__15.MoveNext() in /home/runner/work/ServiceStack/ServiceStack/ServiceStack/src/ServiceStack/Host/ServiceRunner.cs:line 131

This is on the official v6.5 release.

Line 131 ServiceRunner.cs in v6.5 is not an async method:

Do you have the full StackTrace showing the source of the Exception and Exception type?

The error occurs when accessing HttpContext.Current in my code. It seems in some cases it will be null in some requests. This was never a problem before v6.4. In my case, it happens in 2 different requests - a POST and a GET. The code bring run is not async.
Here is a full exception:

Object reference not set to an instance of an object.
   at MyAPI.ServiceInterface.MyService.Post(MyPostRequest request) in C:\Users\Eaton\Source\Workspaces\MyAPI\MyAPI\MyAPI.ServiceInterface\MyService.cs:line 232
   at ServiceStack.Host.ServiceRunner`1.<ExecuteAsync>d__15.MoveNext() in /home/runner/work/ServiceStack/ServiceStack/ServiceStack/src/ServiceStack/Host/ServiceRunner.cs:line 131

The issue is the result of behavior when calling async methods with ConfigureAwait(continueOnCapturedContext:false) which is what libraries should be using for performance and to mitigate potential for deadlocks.

Unfortunately using this in .NET Framework can lose the HttpContext in the returning async hop continuation, so we need to identify where we need to preserve the captured context, which is what we’d want a repro or exact line number to identify.

But I’ve gone ahead and changed it to not use ConfigureAwait(false) when calling user callbacks/filters/services in .NET Framework in latest v6.61+ on MyGet.

Can you try it and let me know if that resolves it, if you still have an issue I’ve added debug logging that logs where HttpContext.Current is null, which should be in the configured debug logger.

Thank you very much for taking the time to apply a potential fix! I have just updated my service - let’s see how it goes.