Action method returns empty response after setting TempData

[kshyju]

When i set an object of my custom class to TempData and try to do a Redirect, I get a 500 error. As per 2.0, CookieTempData provider is default. So i do not have any explicit mapping for ITempDataProvider to CookieTempDataProvider

The code i am trying

    [HttpPost]
    public IActionResult Index(IndexViewModel model)
    {
        model.Code = "This was set in HttpPost at" + DateTime.Now;
        TempData["MyModel"] = model;          
        return RedirectToAction("About","Home");
    }

    public IActionResult About()
    {
        var m = TempData["MyModel"] as IndexViewModel;
        ViewBag.Message = m?.Code ?? " There was nothing in TempData.";
        return View();
    }

This never hits About action method. I inspected the network calls and the browser never gets a 302 response when i submit the form to the HttpPost Index action.

Chrome dev tools shows Status Code:500 Internal Server Error in General header section

Response headers are

HTTP/1.1 500 Internal Server Error
Server: Kestrel
X-SourceFiles: =?UTF-8?B?QzpcdGVtcFxUZW1wRGF0YVxUZW1wRGF0YVxUZW1wRGF0YQ==?=
X-Powered-By: ASP.NET
Date: Mon, 30 Oct 2017 02:29:19 GMT
Content-Length: 0

I have the exception page enabled in Startup, but still not seeing any errors

This is the error message i get in chrome

This page isn’t working

localhost is currently unable to handle this request.
HTTP ERROR 500

--

Here is a minimal repo where i reproduced the issue

[Eilon]

@kshyju can you try catching all exceptions in Visual Studio's debugger to see what the actual exception is?

@pranavkm can you also try to take a look?

[kshyju]

Here is the relevant part of the exception

System.InvalidOperationException: The 'Microsoft.AspNetCore.Mvc.ViewFeatures.Internal.TempDataSerializer' cannot serialize an object of type 'TempData.Controllers.IndexViewModel'.
   at Microsoft.AspNetCore.Mvc.ViewFeatures.Internal.TempDataSerializer.EnsureObjectCanBeSerialized(Object item)
   at Microsoft.AspNetCore.Mvc.ViewFeatures.Internal.TempDataSerializer.Serialize(IDictionary`2 values)
   at Microsoft.AspNetCore.Mvc.ViewFeatures.CookieTempDataProvider.SaveTempData(HttpContext context, IDictionary`2 values)
   at Microsoft.AspNetCore.Mvc.ViewFeatures.TempDataDictionary.Save()
   at Microsoft.AspNetCore.Mvc.ViewFeatures.Internal.SaveTempDataFilter.SaveTempData(IActionResult result, ITempDataDictionaryFactory factory, IList`1 filters, HttpContext httpContext)
   at Microsoft.AspNetCore.Mvc.ViewFeatures.Internal.SaveTempDataFilter.OnResultExecuted(ResultExecutedContext context)

The EnsureObjectCanBeSerialized method is throwing the exception.

Is it by design ? Are we only supposed to use simply types mentioned in IsSimpleType method ? I remember in previous versions of MVC, i could do this. I usually follow the PRG pattern. But there are instances where i would like to pass a small-lean-flat class objects with 2 or 3 properties using TempData.

Here is the simple class i was using

public class IndexViewModel
{
    public string Code { set; get; }
    public bool ShouldSetTempData { set; get; }
}

[pranavkm]

@kshyju yes, the TempDataSerializer only supports simple types and collection (lists and dictionaries) of simple types. #2276 has some background on why it behaves like this and #2276 (comment) has some suggestions on what you could do to address this in your application.

[kshyju]

Thanks ! Any idea why it is not throwing/showing the error message in the browser or firing up the developer exception page ? (I used VS Output->Debug window to get the exception details)

[pranavkm]

Serialization of TempData is one of the few things that happens outside of the middleware pipeline (https://github.com/aspnet/Mvc/blob/dev/src/Microsoft.AspNetCore.Mvc.ViewFeatures/Internal/SaveTempDataFilter.cs#L46) which explains why you don't see the error in the diagnostics middleware.

@Tratcher could we do something to make the experience for reporting errors thrown as part of Response.OnStarting better?

[Tratcher]

OnStarting is called directly by the server, the best it can do is log. In practice we don't use OnStarting in most components because of the ordering and error handling confusion. Do you really need it for temp data? Would you be better off processing temp data as a result filter of some sort?

[halter73]

The diagnostics middleware could wrap OnStarting callbacks and report any exceptions by decorating IHttpResponseFeature. Not saying it's a good idea, but it's possible.

[Tratcher]

Yes, but it would be outside of the request control flow so it couldn't react to the exception.

[pranavkm]

The handling of error scenarios is much better since #6598. Tracking further improvement of error reporting via dotnet/aspnetcore#2851