You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
RestSharp does not behave well with the AspNetSynchronizationContext. Callbacks with in the code leaves the synchronization context. On reentry the context (among other housekeeping) drops Thread.CurrentPrincipal and sets it to HttpContext.Current.User. Which causes problems with projects that have different values for these principals. It is also less efficient to switch the context and will not perform as well in high performance projects. Even if you set UseSynchronizationContext to true for async code, the result is the same. Additionally, setting UseSynchronizationContext to true calls AspNetSynchronizationContext.Post, Which itself has re-entrant behavior. The re-entrant behavior in my experience continues up the chain of async calls every time the code continues after an await. So caching and resetting Thread.CurrentPrincipal after an awaited call only lasts till the end of the method.
For reference: https://blog.stephencleary.com/2009/10/synchronizationcontext-properties.html
I do not have experience with other Synchronization Contexts but I would imagine they could have side effects as well.
An API client with a more current asynchronous implementation would be better. I started to look at Flurl which might be a candidate. https://flurl.dev/. But didn't see synchronous supported calls off hand.
It's beyond me at this point to attempt this sort of update. Hopefully someone else might be up to it.
The text was updated successfully, but these errors were encountered:
I can confirm that RestClient.ExecuteTaskAsync(request) never returns, and because the packaged RestSharp client is 105.1.0 it's swallowing the errors, so we can't diagnose what's happening.
RestSharp does not behave well with the AspNetSynchronizationContext. Callbacks with in the code leaves the synchronization context. On reentry the context (among other housekeeping) drops Thread.CurrentPrincipal and sets it to HttpContext.Current.User. Which causes problems with projects that have different values for these principals. It is also less efficient to switch the context and will not perform as well in high performance projects. Even if you set UseSynchronizationContext to true for async code, the result is the same. Additionally, setting UseSynchronizationContext to true calls AspNetSynchronizationContext.Post, Which itself has re-entrant behavior. The re-entrant behavior in my experience continues up the chain of async calls every time the code continues after an await. So caching and resetting Thread.CurrentPrincipal after an awaited call only lasts till the end of the method.
For reference:
https://blog.stephencleary.com/2009/10/synchronizationcontext-properties.html
I do not have experience with other Synchronization Contexts but I would imagine they could have side effects as well.
An API client with a more current asynchronous implementation would be better. I started to look at Flurl which might be a candidate. https://flurl.dev/. But didn't see synchronous supported calls off hand.
It's beyond me at this point to attempt this sort of update. Hopefully someone else might be up to it.
The text was updated successfully, but these errors were encountered: