[release/10.0] Refactor param binding failure handling in RequestDelegate#66221
Open
github-actions[bot] wants to merge 4 commits intorelease/10.0from
Open
[release/10.0] Refactor param binding failure handling in RequestDelegate#66221github-actions[bot] wants to merge 4 commits intorelease/10.0from
github-actions[bot] wants to merge 4 commits intorelease/10.0from
Conversation
Refactor `RequestDelegateFactory` to handle parameter binding failures more flexibly: - Execute filter pipelines on failure if filters are present and return type is `ValueTask<object?>`, allowing filters to observe/modify the 400 response. - Short-circuit with a 400 response if no filters are present. - Simplify logic using `Expression.Condition` and `Expression.Block`. Add new test cases in `RouteHandlerEndpointRouteBuilderExtensionsTest.cs`: - Validate behavior with/without filters and custom responses. - Ensure handlers are not executed on binding failure.
… between RDG/RDF This confirm that the behavior is the same across runtime and compile-time generated handler implementations.
Added explanatory comments to RequestDelegateFactory describing the checkWasParamCheckFailure conditional expression. These comments clarify how parameter binding or validation failures result in a 400 response, while successful checks invoke the handler method. No functional changes were made.
…e proper response status
github-actions
bot
requested review from
BrennanConroy and
halter73
as code owners
github-actions
bot
added
the
area-networking
Member
|
cc @artl93 for servicing consideration. |
artl93
approved these changes
Apr 9, 2026
Member
artl93
left a comment
artl93
left a comment
There was a problem hiding this comment.
Newer feature in 10.0 exposed this issue more prominently. Current behavior is unexpected. Customer reported. Approved.
BrennanConroy
added
the
Servicing-consider
BrennanConroy
added
Servicing-approved
Contributor
|
Hi @github-actions[bot]. This PR was just approved to be included in the upcoming servicing release. Somebody from the @dotnet/aspnet-build team will get it merged when the branches are open. Until then, please make sure all the CI checks pass and the PR is reviewed. |
halter73
approved these changes
Apr 9, 2026
Member
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backport of #64539 to release/10.0
/cc @BrennanConroy @marcominerva
Refactor param binding failure handling in RequestDelegate
Description
Validation support was added in 10.0.
It works by adding an endpoint filter that checks if an endpoint should have validation applied to it, if it does then it wraps the endpoint delegate in a new delegate that will run validation, otherwise it just returns the original endpoint delegate without wrapping it.
The bug, which looks like it's existed for years, is that if an endpoint filter returns the original endpoint delegate we would think that a filter had been wrapped around the original delegate and still call it for failed parameter binding, even though the delegate was never wrapped. This resulted in the endpoint being called when it normally shouldn't be.
e.g.
In the above snippet, if validation is added via
AddValidationon the service collection, then a request to/x/invalid-guidwould still call theid.ToString()code even though we've set a 400 status code and shouldn't be calling the delegate.Fixes #64341
Not planning on backporting to 9.0 and 8.0 since we haven't seen complaints for those versions and validation is new in 10.0 which is the main motivator for backporting this.
Customer Impact
Highly requested bug fix, and blocking some customers from using the new validation feature.
Regression?
Validation is new in 10.0, and the bug has been there since before 10.0.
Risk
Improved test coverage, simple fix.
Verification
Packaging changes reviewed?