Inconsistent flow of ExecutionContext on first batch of client requests
- Dominant language
- C#
- Stars
- 1.8k
- Forks
- 576
- Avg merge
- 6d 9h
- Merged PRs (30d)
- 2
Description
**Describe the bug**
It seems there is an incorrect flow of data stored in ExecutionContext whenever there are multiple async requests executed concurrently after the first initialization of ServiceModel WCF client. In case there is an DelegatingHandler registered to the underlying HttpClient, the flow of ExecutionContext is inconsistent here. Apparently only the first thread can access the same data in ExecutionContext and any other request executed concurrently with the first one will not be able to access the same ExecutionContext's data in the DelegatingHandler. This behavior seems to be consistent and it happens only during the first batch of requests done simultaneously. After the first batch any subsequent requests are sharing the same data in ExecutionContext as expected throughout the whole lifetime of the ServiceModel client.
**To Reproduce**
- initialize instance of ServiceModel WCF client
- register DelegatingHandler in IEndpointBehavior's AddBindingParameters method
- store some data into ExecutionContext using AsyncLocal
- execute at least 2 requests simultaneously
**Expected behavior**
All of the threads executed simultaneously during the first batch of requests to the ServiceModel client are able to access the same ExecutionContext data.
**Actual Behavior**
Only the first thread is able to access the same ExecutionContext data. Any other thread will not be able to access the same data in ExecutionContext
IMHO, I believe this could be potentially critical because there might be some authorization checks in place that are utilizing the HttpContext retrieved via IHttpContextAccessor and since we cannot rely on the correct flow of ExecutionContext the HttpContext would not be available in the DelegatingHandler and therefore the whole authorization could possibly fail without meaningful reason. Also, it seems there are no easy workarounds for this since the DelegatingHandlers are not respecting the scoped lifetime in DI and should be always transient.
I've prepared a small project to demonstrate this behavior with all the necessary details: https://github.com/fi1ipO/wcf-async
Affected version of ServiceModel packages: 4.10.0
Contributor guide
Assessment
This issue has not been assessed yet.