ProblemDetails payload differs between Development and custom environment for JSON model-binding failure (Minimal APIs + AddProblemDetails + UseExceptionHandler)

[vadimt2]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When a Minimal API endpoint binds a request body to a record with an int property and the client sends an invalid value (e.g., "a"), the response body for HTTP 400 differs between environments, despite using AddProblemDetails() and UseExceptionHandler().

• In Development environment, the response includes exception details with "type": "BadHttpRequestException" and a descriptive detail.

• In a custom environment (e.g., Test), the response is a generic RFC 9110 problem with "type": "https://tools.ietf.org/html/rfc9110#section-15.5.1" and no detail.

This inconsistency makes it difficult to rely on a stable ProblemDetails shape across environments for client handling and observability.

Expected Behavior

In test Environment:
{
"type": "BadHttpRequestException",
"title": "An error occurred",
"status": 400,
"detail": "Failed to read parameter "TestRequest request" from the request body as JSON.",
"instance": "POST /weatherforecast"
}

Steps To Reproduce

You can clone my repo and just change the Environment for development and the second time for test.
https://github.com/vadimt2/net8-CustomException-issue

1. Create a new **.NET 8 Minimal API** project:

   ```bash
   dotnet new web -n ReproApp
   cd ReproApp

2. Replace Program.cs with:

   var builder = WebApplication.CreateBuilder(args);
   
   builder.Services.AddEndpointsApiExplorer();
   builder.Services.AddSwaggerGen();
   
   builder.Services.AddProblemDetails();
   builder.Services.AddExceptionHandler<ExceptionHandler>();
   
   var app = builder.Build();
   
   if (app.Environment.IsDevelopment() || app.Environment.IsEnvironment("test"))
   {
       app.UseSwagger();
       app.UseSwaggerUI();
   }
   
   app.UseHttpsRedirection();
   app.UseExceptionHandler();
   app.UseStatusCodePages();
   
   app.MapPost("/weatherforecast", (TestRequest request) =>
   {
       return Results.Ok();
   });
   
   app.Run();
   
   public record TestRequest(int number);
   
   class ExceptionHandler : Microsoft.AspNetCore.Diagnostics.IExceptionHandler
   {
       public ValueTask<bool> TryHandleAsync(HttpContext httpContext, Exception exception, CancellationToken cancellationToken)
           => new(false);
   }

3. In Properties/launchSettings.json, add two profiles that differ only in ASPNETCORE_ENVIRONMENT:

   "profiles": {
     "https (Development)": {
       "commandName": "Project",
       "applicationUrl": "https://localhost:7221;http://localhost:5041",
       "environmentVariables": {
         "ASPNETCORE_ENVIRONMENT": "Development"
       }
     },
     "https (Test)": {
       "commandName": "Project",
       "applicationUrl": "https://localhost:7221;http://localhost:5041",
       "environmentVariables": {
         "ASPNETCORE_ENVIRONMENT": "Test"
       }
     }
   }

4. Run the app with the Development profile and send:

   POST https://localhost:7221/weatherforecast
   Content-Type: application/json
   
   { "number": "a" }

   Response:

   {
     "type": "BadHttpRequestException",
     "title": "An error occurred",
     "status": 400,
     "detail": "Failed to read parameter \"TestRequest request\" from the request body as JSON.",
     "instance": "POST /weatherforecast"
   }

5. Run the app with the Test profile and send the same request:

   Response:

   {
     "type": "https://tools.ietf.org/html/rfc9110#section-15.5.1",
     "title": "Bad Request",
     "status": 400
   }

Exceptions (if any)

No response

.NET Version

8.0.18

Anything else?

please clone the repo
https://github.com/vadimt2/net8-CustomException-issue

use swagger for testing

{
"number": "a"
}

send a request with: Development and Test
you will see a different result, both of the results should be the same as Development

[martincostello]

you will see a different result, both of the results should be the same as Development

I believe this is by design - outside of Development the known non-production environment, other environments are assumed to be "production" environments for security reasons to prevent unintentional information disclosure.

I can't quickly find the exact line of code that's making the decision to return the two different responses, but if you want Test to behave the same as Development you'll need to customise the problem details and/or exception handler code to do so.

[vadimt2]

Thanks for the quick response! I understand the security rationale for hiding details outside Development. *Two asks:* 1. Could you point me to the doc/source that governs the different ProblemDetails payloads for body-binding failures (e.g., BadHttpRequestException) across environments? I couldn’t find it. 2. If this is by design, can we have an officially documented way (or option) to *keep the payload shape consistent* across environments (e.g., same type/title, optional detail) without hand-rolling a custom exception handler? In the meantime I can customize AddProblemDetails to match Development in my Test env. Posting a minimal snippet below in case it helps others.

…

On Tue, Aug 19, 2025, 12:42 Martin Costello ***@***.***> wrote: *martincostello* left a comment (dotnet/aspnetcore#63331) <#63331 (comment)> you will see a different result, both of the results should be the same as Development I believe this is by design - outside of Development the known non-production environment, other environments are assumed to be "production" environments for security reasons to prevent unintentional information disclosure. I can't quickly find the exact line of code that's making the decision to return the two different responses, but if you want Test to behave the same as Development you'll need to customise the problem details and/or exception handler code to do so. — Reply to this email directly, view it on GitHub <#63331 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKGQ6TQPRQEU22SPSNKT24T3OLWRFAVCNFSM6AAAAACEHURNM2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTEMBQGAYTMOBWGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[martincostello]

Could you point me to the doc/source that governs the different ProblemDetails payloads for body-binding failures

I already said I couldn't find it 😄:

I can't quickly find the exact line of code that's making the decision

I suggest you clone the code yourself locally and look through it to find the appropriate location.

If this is by design, can we have an officially documented way...

I believe this is the appropriate documentation. If you feel it should be improved then that should be an issue for dotnet/AspNetCore.Docs.

Development behaves differently because that's almost always what you're using locally with the debugger, so behaves differently to make you more productive when debugging in an IDE.

If you want consistent behaviour, then if you want "production" to behave the same as development, then that's something you need to use with the built-in customization hooks.

Personally, I would go for consistency by having development match production, not the other way around (because it's more secure), but the trade off there is it makes it harder to find the sources of bugs when you're developing locally.

[vadimt2]

✅ Thanks — enabling builder.Services.Configure<RouteHandlerOptions>(o => o.ThrowOnBadRequest = true); does the trick. With this setting, body-binding failures (e.g. "number": "a" for an int) now throw BadHttpRequestException instead of returning a bare 400, so my CustomExceptionHandler can handle it and format the ProblemDetails consistently across environments.

…

On Tue, Aug 19, 2025 at 12:52 PM Martin Costello ***@***.***> wrote: *martincostello* left a comment (dotnet/aspnetcore#63331) <#63331 (comment)> Could you point me to the doc/source that governs the different ProblemDetails payloads for body-binding failures I already said I couldn't find it 😄: I can't quickly find the exact line of code that's making the decision I suggest you clone the code yourself locally and look through it to find the appropriate location. If this is by design, can we have an officially documented way... I believe this <https://learn.microsoft.com/aspnet/core/web-api/handle-errors> is the appropriate documentation. If you feel it should be improved then that should be an issue for dotnet/AspNetCore.Docs <https://github.com/dotnet/AspNetCore.Docs>. Development behaves differently because that's almost always what you're using locally with the debugger, so behaves differently to make you more productive when debugging in an IDE. If you want consistent behaviour, then if you want "production" to behave the same as development, then that's something you need to use with the built-in customization hooks. Personally, I would go for consistency by having development match production, not the other way around (because it's more secure), but the trade off there is it makes it harder to find the sources of bugs when you're developing locally. — Reply to this email directly, view it on GitHub <#63331 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKGQ6TU2CJR5O74ZJIEI4Z33OLXUNAVCNFSM6AAAAACEHURNM2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTEMBQGA2DOMZTG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>