-
Notifications
You must be signed in to change notification settings - Fork 10.3k
Output formatter unexpectedly returns new instance of scoped service #61803
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
Comments
My hunch is that the issue is because you're using The fix would be to set the property directly in the middleware before returning, or to introduce some other mechanism to ensure no code that needs the value runs before the Task to set it has completed. You can check that you're getting the same instance in the required places by doing something like calling |
The "InvokeAsync" of middleware is executed before request handling in controller and the "WriteResponseBodyAsync" of output formatter is executed after request handling in controller. I don't think there's a "get before set". We also tried to set the value into HttpContext.Items in the middleware and it can successfully got back in output formatter.
|
Can you turn on logging and if possible provide a minimal repro app? This seems like it'll be a difficult issue to figure out. Side-note: wondering why you don't use: |
We logged hashcode of objects and found out when issue happens, the hashcode of HttpContext instance is same in middleware and output formatter. However, httpConext.RequestServices shows a different hashcode in middleware and output formatter. I didn't find any RequestServices reassign code in our repo. I'm not sure if there's minimal repro. Will try. |
If the service collections are different, that's probably because one is the app's root service collection, and the other is the scoped service collection for an individual HTTP request. |
Try turning on scope validation so if it tries to get a scoped service from the root container it'll fail? Also, since you're logging hashcodes, try logging the hashcode for the |
The validation only happens on service startup? It won't help then. |
Pretty sure it validates every time a service is created/accessed.
It shouldn't change unless app code modifies it We fallback to |
Is there an existing issue for this?
Describe the bug
We have a middleware and a scoped service "IRequestTelemetryContext " in our service.
Then we initialized the scoped service in the middleware. Simplified code:
The "StartTimeStamp" is not updated by any other code. Then, in output formatter, we get its value back. Simplified code:
The issue is that occasionally (at low frequency) the "StartTimeStamp" returned is DateTime.MinValue instead of the value we set in middleware. It's unexpected. Scoped service is supposed to be the same instance throughout the request.
Expected Behavior
startTimeStamp should not be the default value of DateTime.
Steps To Reproduce
No response
Exceptions (if any)
No response
.NET Version
No response
Anything else?
Project target framework is net8.0
The text was updated successfully, but these errors were encountered: