Currently if you return T in an action that returns ActionResult<T> it will create an ObjectResult. The problem is that the StatusCode remains null rather than 200, even though the eventual response generated from it will be 200.

This makes it confusing in, for example, an action filter, where a developer may only want to handle Ok object results on the executed context, including where T is returned directly. They may:

• Safe cast to OkObjectResult and find null
• Better, they safe cast to ObjectResult which works but then find StatusCode is null

They may not handle the result as they should as it's not obvious that a null StatusCode would eventually wind up as a 200 in the response. It seems to be an implementation detail that could easily change.

The assumption is always that returning T will result in a 200 OK (e.g. documentation mentions how you can leave out the T type in a ProducesResponseType attribute for 200 when using ActionResult<T>).

Can this be further enforced by creating an OkObjectResult (which will set StatusCode to 200 in its constructor)? If not, perhaps just an ObjectResult as it currently does, but setting StatusCode to 200 with member initialisation?

Is there perhaps room for improvement in documentation about any of this? Happy to be pointed to anything that makes it explicit how response status codes are created from result status codes including when the result status code is null etc.