title: Unexplained async/await problem with Azure Storage Table access - is it OK to solve with ConfigureAwait(false)? Probably NOT
body: <p>I'm in the third month of working on a new ASP.NET Framework WebApi app that is deployed to Azure.</p>
  <p>I don't need to persist all that much data, but the data I do persist is in Azure Storage Tables.</p>
  <p>About a week ago after weeks of no problems, I started running into trouble with async/await synchronization, seemingly out of the blue.  I was able to localize that problem to awaited asyncronous execution of access to Azure Storage Tables.  Here is a very simplified schematic of how my app works:</p>
  <pre><code>using System.Threading.Tasks;
  using System.Web.Hosting;
  using System.Web.Http;
  using Microsoft.WindowsAzure.Storage;
  using Microsoft.WindowsAzure.Storage.Table;
  
  public class DummyController : ApiController
  {
      public async Task Post()
      {
          string payloadDescribingWork = await Request.Content.ReadAsStringAsync();  // Await here - request is disposed before async task queued.
  
          // Service that hooks by posting to me needs a 204 response immediately,
          // which is why I queue a background work item for the real work.
          // Background work item will never take longer than 30 seconds,
          // but caller will time out if I don't respond 
          HostingEnvironment.QueueBackgroundWorkItem(async cancellationToken =&gt;
          {
              await Task.Delay(3000, cancellationToken); // Simulate some work based on the payload above
  
              CloudStorageAccount storageAccount = CloudStorageAccount.Parse(&quot;MyConnectionString&quot;);
              CloudTableClient tableClient = storageAccount.CreateCloudTableClient();
              CloudTable table = tableClient.GetTableReference(&quot;MyTableName&quot;);
              table.CreateIfNotExists();
  
              // Sometimes but not always, this next awaitable async insert operation will NEVER return
              // In that case the background work item will never complete and will only
              // ever go away when IIS cycles the thread pool.
              // However, if you look at the table with a table explorer, the row actually WAS successfully
              // inserted, even when this operation hangs.
              TableResult noConfigureAwaitResult = 
                  await table.ExecuteAsync(TableOperation.Insert(new TableEntity
                  {
                      PartitionKey = &quot;MyPartitionKey&quot;,
                      RowKey = &quot;MyRowKey&quot;
                  }), cancellationToken);
  
              // The following awaitable async insert operation wrapped with &quot;ConfigureAwait(false)&quot;
              // will always return and always succeed.
              TableResult configureAwaitFalseResult = 
                  await table.ExecuteAsync(TableOperation.Insert(new TableEntity
                  {
                      PartitionKey = &quot;MyOtherPartitionKey&quot;,
                      RowKey = &quot;MyOtherRowKey&quot;
                  }), cancellationToken).ConfigureAwait(false);
          });
  
          // 204 response will be issued right away here by the web api framework.
      }
  }
  </code></pre>
  <p>To reiterate what is in the comments of the snippet, sometimes but not always the access to the storage table using the <code>CloudTable.ExcecuteAsync()</code> method will simply hang forever, suggesting a deadlock, but if I append <code>.ConfigureAwait(false)</code> to the call, it always works fine.</p>
  <p>The problem is I don't understand WHY.  It feels good to get my code working of course, but this may be masking a deeper problem.</p>
  <p>So to the questions:</p>
  <ol>
  <li>Given that my actual queued background work is much more complicated, anyone wish to hazard a guess as to why the storage table access hangs sometimes when not wrapped with <code>.ConfigureAwait(false)</code>?  Please note that I have made every exhaustive audit through my application to ensure that I am using async/await consistently up and down the callstack.</li>
  <li>Given that I am able to get my application to work just fine by wrapping all Azure Storage Access operations with <code>ConfigureAwait(false)</code>, does anyone have an argument as to why this might be a terrible solution over the long term?</li>
  </ol>