Improve Results.Problem and Results.ValidationProblem APIs

[captainsafia]

Description

In .NET 6, we introduced new extension methods as shorthands for creating Results types from endpoint. However, due to an error, we missed adding a parameter to the Results.Problem and Results.ValidationProblem to align with the Extensions property available in those types.

As a result of this, customers are not able to return ProblemDetails or HttpValidationProblemDetails with a configured Extensions type from their APIs.

Customer Impact

Without this fix, customers are not able to return to return ProblemDetails objects

There are no desirable workarounds for this issue since the Results.Problem and Results.ValidationProblem provide a public abstraction over a lot of currently internal functionality, like setting sensible defaults for the title and type of ProblemDetails.

Regression?

• Yes
• No

Risk

• High
• Medium
• Low

Low risk because:

• This change resolves an existing gap in the in the Results extension methods API.

Verification

• Manual (required)
• Automated

Packaging changes reviewed?

• Yes
• No
• N/A

---

Background and Motivation

The Results.Problem and Results.Validation extension methods do not provide a way for users to customize the Extensions property on the resulting ProblemDetails payload.

To support these scenarios, we are adding the extensions parameter to the existing methods and adding new overloads that takes a ProblemDetails or HttpValidationProblemDetails object to provide further customizability for users.

Proposed API

namespace Microsoft.AspNetCore.Http
{
    public static class Results
    {
        public static IResult Problem(
            string? detail = null,
            string? instance = null,
            int? statusCode = null,
            string? title = null,
            string? type = null,
+           IDictionary<string, object?>? extensions = null)
        {
            ...
        }

+       public static IResult Problem(ProblemDetails problemDetails) { ... }

        public static IResult ValidationProblem(
            IDictionary<string, string[]> errors,
            string? detail = null,
            string? instance = null,
            int? statusCode = null,
            string? title = null,
            string? type = null,
+           IDictionary<string, object?>? extensions = null)
        {
            ...
        }
    }
}

Usage Examples

// {
//   "type": "https://tools.ietf.org/html/rfc7231#section-6.6.1",
//   "title": "An error occurred while processing your request.",
//   "status": 500,
//   "green": "foo"
// }
app.MapGet("/sample1", () => 
    Results.Problem(statusCode: 500, extensions: new Dictionary<string, object?>() { { "green", "foo" } }));
// {
//   "type": "https://tools.ietf.org/html/rfc7231#section-6.6.1",
//   "title": "An error occurred while processing your request.",
//   "status": 500,
//   "green": "foo"
// }
app.MapGet("/sample2", () => 
    Results.Problem(new ProblemDetails() { Status = 500, Extensions = { { "green", "foo"}}}));
var errors = new Dictionary<string, string[]>();
// {
//   "type": "https://tools.ietf.org/html/rfc7231#section-6.5.1",
//   "title": "Bad Request",
//   "status": 400,
//   "green": "foo",
//   "errors": {
    
//   }
// }
app.MapGet("/sample3", () =>
    Results.ValidationProblem(errors, statusCode: 400, extensions: new Dictionary<string, object?>() { { "green", "foo" } }));
// {
//     "type": "https://tools.ietf.org/html/rfc7231#section-6.5.1",
//     "title": "One or more validation errors occurred.",
//     "status": 400,
//     "green": "foo",
//     "errors": {
        
//     }
// }
app.MapGet("/sample4", () => 
    Results.Problem(new HttpValidationProblemDetails(errors) { Status = 400, Extensions = { { "green", "foo"}}}));

Fixes #36848

[BrennanConroy]

Add a few smoke tests that the extensions are there and the new overloads work?

[ghost]

"Hi captainsafia. Please make sure you've updated the PR description to use the Shiproom Template. Also, make sure this PR is not marked as a draft and is ready-to-merge.

To learn more about how to prepare a servicing PR click here.

[captainsafia]

Closing since we decided to target release/6.0 instead of release/6.0-rc2 with this and I'll need to re-open a separate PR.

[captainsafia]

Closing since we decided to target release/6.0 instead of release/6.0-rc2 with this and I'll need to re-open a separate PR.

Re-opening since this was Servicing approved for RC2. See #36884 (comment).

[captainsafia]

@dotnet/aspnet-build Can I get help merging?