Restore custom status code response functionality for exceptions thrown outside of HttpActionInvoker

Author: C0nquistadore

src/Dibix.Http.Host/Program.cs

@@ -68,6 +68,7 @@ void ConfigureLogging(ILoggingBuilder logging)
                     .AddTransient<IPostConfigureOptions<JsonOptions>, JsonPostConfigureOptions>()
                     .AddSingleton<IControllerActivator, NotSupportedControllerActivator>();
 
+            services.AddExceptionHandler<DatabaseAccessExceptionHandler>();
             services.AddExceptionHandler<HttpRequestExecutionExceptionHandler>();
             services.AddProblemDetailsWithMapping()
                     .Map<HttpRequestExecutionException>(x => x.IsClientError, (x, y) =>

src/Dibix.Http.Host/Runtime/DatabaseAccessExceptionHandler.cs

@@ -0,0 +1,27 @@
+using System;
+using System.Threading;
+using System.Threading.Tasks;
+using Dibix.Http.Server;
+using Microsoft.AspNetCore.Diagnostics;
+using Microsoft.AspNetCore.Http;
+
+namespace Dibix.Http.Host
+{
+    // Map sql error codes to http status codes globally
+    // This is needed if a DatabaseAccessException is thrown outside HttpActionInvoker. For example, within the http host extension.
+    internal sealed class DatabaseAccessExceptionHandler : HttpRequestExecutionExceptionHandler, IExceptionHandler
+    {
+        public DatabaseAccessExceptionHandler(IProblemDetailsService problemDetailsService) : base(problemDetailsService) { }
+
+        public override async ValueTask<bool> TryHandleAsync(HttpContext httpContext, Exception exception, CancellationToken cancellationToken)
+        {
+            if (exception is not DatabaseAccessException databaseAccessException)
+                return false;
+
+            if (SqlHttpStatusCodeParser.TryParse(databaseAccessException, out HttpRequestExecutionException httpRequestExecutionException))
+                return await base.TryHandleAsync(httpContext, httpRequestExecutionException, cancellationToken).ConfigureAwait(false);
+
+            return false;
+        }
+    }
+}

src/Dibix.Http.Host/Runtime/HttpRequestExecutionExceptionHandler.cs

@@ -9,7 +9,7 @@
 namespace Dibix.Http.Host
 {
     // Map custom HTTP status codes to response
-    internal sealed class HttpRequestExecutionExceptionHandler : IExceptionHandler
+    internal class HttpRequestExecutionExceptionHandler : IExceptionHandler
     {
         private readonly IProblemDetailsService _problemDetailsService;
 
@@ -18,8 +18,25 @@ public HttpRequestExecutionExceptionHandler(IProblemDetailsService problemDetail
             _problemDetailsService = problemDetailsService;
         }
 
-        public ValueTask<bool> TryHandleAsync(HttpContext httpContext, Exception exception, CancellationToken cancellationToken) => TryHandleWithProblemDetails(httpContext, exception);
-        
+        public virtual ValueTask<bool> TryHandleAsync(HttpContext httpContext, Exception exception, CancellationToken cancellationToken) => TryHandleWithProblemDetails(httpContext, exception);
+
+        protected static bool HandleHttpRequestExecutionException(HttpContext httpContext, HttpRequestExecutionException httpRequestExecutionException)
+        {
+            httpContext.Response.StatusCode = (int)httpRequestExecutionException.StatusCode;
+
+            // For compatibility reasons
+            // TODO: Remove, once problem details are stabilized
+            httpRequestExecutionException.AppendToResponse(httpContext.Response);
+
+            // Note: The ExceptionHandlerMiddleware will log the exception even if the handler returns true
+            // See: https://github.com/dotnet/aspnetcore/issues/54554
+            // If client exceptions should not be logged, we can do the following:
+            // - Implement a custom IExceptionHandler
+            // - Use LogError with a custom log category (i.E. the name of the handler, something like 'HttpStatusCodeClientExceptionHandler')
+            // - Set this category's log level to 'Critical' by default, to avoid logging client exceptions
+            return true;
+        }
+
         // TODO: Instead of writing problem details manually, use the StatusCodeSelector introduced in .NET 9
         // See: https://www.milanjovanovic.tech/blog/problem-details-for-aspnetcore-apis#handling-specific-exceptions-status-codes
         private async ValueTask<bool> TryHandleWithProblemDetails(HttpContext httpContext, Exception exception)
@@ -41,19 +58,7 @@ private static bool TryHandle(HttpContext httpContext, Exception exception)
             if (exception is not HttpRequestExecutionException httpRequestExecutionException)
                 return false;
 
-            httpContext.Response.StatusCode = (int)httpRequestExecutionException.StatusCode;
-
-            // For compatibility reasons
-            // TODO: Remove, once problem details are stabilized
-            httpRequestExecutionException.AppendToResponse(httpContext.Response);
-
-            // Note: The ExceptionHandlerMiddleware will log the exception even if the handler returns true
-            // See: https://github.com/dotnet/aspnetcore/issues/54554
-            // If client exceptions should not be logged, we can do the following:
-            // - Implement a custom IExceptionHandler
-            // - Use LogError with a custom log category (i.E. the name of the handler, something like 'HttpStatusCodeClientExceptionHandler')
-            // - Set this category's log level to 'Critical' by default, to avoid logging client exceptions
-            return true;
+            return HandleHttpRequestExecutionException(httpContext, httpRequestExecutionException);
         }
     }
 }