-
Notifications
You must be signed in to change notification settings - Fork 10.3k
HeaderPropagation: reset AsyncLocal per request #15435
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Trouble with this is if there is an httprequest that happens with lag on a previous request due to fire and forgot (which would be likely problematic anyway) it will pick up the changed dictionary from the async local. Either would need to make the |
Thanks Ben for the quick feedback. |
@@ -36,7 +36,8 @@ public HeaderPropagationMiddleware(RequestDelegate next, IOptions<HeaderPropagat | |||
public Task Invoke(HttpContext context) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would also make this method async
As Kestrel can bleed the AsyncLocal across requests, see dotnet#13991.
e2fa07a
to
5c0edec
Compare
Changed approach and made the middleware async as suggested. |
@davidfowl didn't you fix this in 5.0 in Kestrel? |
Why not just take #14027 instead? |
would it be possible to include this in 3.1 given it is a bugfix, and eventually remove it for 5.0 once one of the global fixes lands? |
We need to land on which of these we take, this PR or #14146 . Consensus in triage seems to lean towards #14146 . As to backporting to 3.1, that will be open as an option once we merge to |
We're going to close this in lieu of #14146 . If that doesn't land, we can revisit. |
As Kestrel can bleed the AsyncLocal across requests,
see #13991.
Addresses #15384
/cc @benaadams @davidfowl