fix: add RequestDelegate to ExceptionMiddleware constructor

[nanotaboada]

The middleware was using primary constructor syntax but was missing the RequestDelegate next parameter, causing dependency injection to fail at runtime with InvalidOperationException.

Fixed by adding RequestDelegate next as the first parameter in the primary constructor and removing it from InvokeAsync method signature, which is the correct pattern for ASP.NET Core middleware.

Summary by CodeRabbit

• Refactor
  • Internal improvements to exception handling middleware architecture.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

The ExceptionMiddleware class is refactored to follow the standard ASP.NET Core middleware pattern by moving the RequestDelegate next dependency from the InvokeAsync method signature to the constructor, aligning with conventional middleware architecture.

Changes

Cohort / File(s)	Summary
Middleware Pattern Refactoring src/Dotnet.Samples.AspNetCore.WebApi/Middlewares/ExceptionMiddleware.cs	Constructor updated to accept RequestDelegate next as first parameter; InvokeAsync method signature simplified from (HttpContext context, RequestDelegate next) to (HttpContext context)

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

• Verify that RequestDelegate next is properly stored as a private field in the constructor
• Confirm InvokeAsync invokes the stored delegate correctly at the end of exception handling logic
• Ensure no behavioral changes in the middleware pipeline execution flow

Possibly related PRs

• feat: add global exception handling middleware with RFC 7807 support #321: Directly modifies the same ExceptionMiddleware class and its middleware wiring patterns

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title uses Conventional Commits format (fix:), is 59 characters (under 80), and accurately describes the main change: adding RequestDelegate to the ExceptionMiddleware constructor to fix a runtime dependency injection issue.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 75.00%.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/exception-middleware-constructor

---

📜 Recent review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between cff7431 and 526e4cb.

📒 Files selected for processing (1)

• src/Dotnet.Samples.AspNetCore.WebApi/Middlewares/ExceptionMiddleware.cs (2 hunks)

🧰 Additional context used

📓 Path-based instructions (1)

**/*.cs

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

**/*.cs: Use PascalCase for class names, methods, and public properties in C#
Use camelCase for local variables and private fields in C#
Use async/await consistently for asynchronous code in C#
Prefer var for local variable declarations where the type is obvious in C#
Nullable reference types are enabled in C# projects
Use CSharpier formatting standards for code style in C#
Do not use ConfigureAwait(false) in ASP.NET Core contexts in C#
Implement proper logging with structured logging patterns using ILogger<T> in ASP.NET Core
Format C# code using CSharpier for consistent code style across the project

Files:

• src/Dotnet.Samples.AspNetCore.WebApi/Middlewares/ExceptionMiddleware.cs

---

⚙️ CodeRabbit configuration file

**/*.cs: - Follow C# naming conventions: PascalCase for classes/methods/properties, camelCase for local variables

• Ensure nullable reference types are handled properly
• Verify async/await patterns are used consistently
• Check for proper dependency injection usage
• Validate that var is used appropriately for obvious types
• Ensure ILogger is used for logging, not Console.WriteLine
• Code should follow CSharpier formatting standards

Files:

• src/Dotnet.Samples.AspNetCore.WebApi/Middlewares/ExceptionMiddleware.cs

⏰ Context from checks skipped due to timeout of 120000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: Codacy Static Code Analysis
• GitHub Check: Analyze (csharp)

🔇 Additional comments (2)

src/Dotnet.Samples.AspNetCore.WebApi/Middlewares/ExceptionMiddleware.cs (2)

11-15: LGTM! Critical fix correctly implements the ASP.NET Core middleware pattern.

The addition of RequestDelegate next as the first constructor parameter resolves the dependency injection failure. This follows the standard middleware convention where RequestDelegate must be constructor-injected to enable the ASP.NET Core pipeline to wire up middleware correctly. The use of C# primary constructor syntax is clean and appropriate here.

---

25-35: LGTM! Method signature and pipeline invocation are correct.

The InvokeAsync signature now correctly accepts only HttpContext as a parameter, while the RequestDelegate next is accessed from the constructor-injected field (line 29). This aligns with ASP.NET Core middleware conventions and ensures proper integration with the request pipeline.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
✅ +0.00%	✅ ∅

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (cff7431)	1225	196	16.00%
Head commit (526e4cb)	1225 (+0)	196 (+0)	16.00% (+0.00%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#333)	0	0	∅ (not applicable)

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences