Separate synchronous and asynchronous code paths

Most of our public API has both synchronous and asynchronous versions of service methods. Due to the big amount of logic that is identical in both synchronous and asynchronous code paths, it is acceptable to have common non-public asynchronous methods that handle both code paths.

However, synchronous execution of asynchronous method may result in any of the following issues:

• Waiting for incomplete ValueTask. When ValueTask is created from IValueTaskSource, it is not guaranteed to return proper value (or any value at all) if GetAwaiter().GetResult() is called before task is completed. For example, implementation of InteractiveBrowserCredential has such issue: GetTokenImplAsync will return incomplete task to the GetToken while awaiting for AcquireTokenSilentAsync. See docs for details.
• Causing a deadlock on synchronization contexts. Any single-threaded SynchronizationContext (the most common are the ones in WPF and WinForms UI threads) will hang if GetAwaiter().GetResult() is called on non-completed task in the sync context thread, and code after await operator is scheduled to be executed by the same SynchronizationContext. While ConfigureAwait(false) creates an awaitable object that forces async state machine to continue on thread pool, deadlocks are still possible.
• Using additional thread. When GetAwaiter().GetResult() is called on non-completed task, async state machine will execute code after await on a second thread, while first thread remains blocked. This may easily lead to thread-pool starvation.
• Causing a deadlock on callbacks. Consider the following example:

  public class Service {
      public Func<bool> Callback { get; set; }
      public void Execute() => ExecuteAsyncImpl().GetAwaiter().GetResult();
      private async Task ExecuteAsyncImpl() {
          // Do some work
          await Task.Delay(100).ConfigureAwait(false);
          if (Callback()) {
              // Do some work
              await Task.Delay(100).ConfigureAwait(false);
          }
      }
  }
  

  If user code synchronously calls ExecuteAsync from UI thread and Callback also requires UI thread, there will be a deadlock:

  private void Button_OnClick(object sender, RoutedEventArgs e) {
      var dispatcher = Dispatcher.CurrentDispatcher;
      var service = new Service { Callback = () => dispatcher.Invoke(AskUser) };
      service.Execute();
  }
  

To avoid issues described above, GetAwaiter().GetResult() must be called only on tasks that are already completed, which can be guaranteed only if asynchronous method is executed synchronously. For that, method should have a bool async parameter that is either used explicitly in conditional operators to avoid asynchronous awaiting, or passed directly into other asynchronous method with bool async parameter.

[jsquire]

@AlexanderSher: Given the age of this and the number of enhancements made to Azure.Core since, can you give a quick look as to whether there is still work to be done here or this issue is stale? If no longer needed, please close it out.

[jsquire]

@pallavit : Yes; the work for this was done quite a while back. Outside of a few special cases, all the sync calls should be using EnsureCompleted and an analyzer is in place to enforce that convention.