ConfigureAwait() call when sending mail using new API

[steve-tapley]

Hi,

I'm migrating my code from v6 to v8.

Previously, I would send an email like this:
var transportWeb = new Web(SendGridApiKey); await transportWeb.DeliverAsync(emailMessage).ConfigureAwait(false);
With v8, I am required to do something like this:
var mailClient = new SendGridAPIClient(SendGridApiKey); dynamic response = await mailClient.client.mail.send.post(requestBody: mail.Get());

The code is missing ConfigureAwait(false) - and as far as I am aware, this is required for proper async handling.

Due to the dynamic nature of the API, i can add it, but this results in an exception with the message:
'System.Runtime.CompilerServices.ConfiguredTaskAwaitable<SendGrid.CSharp.HTTP.Client.Response>'

So, how can I add ConfigureAwait(false) to make this follow the async guidelines?

Thanks,
Steve

[M3LiNdRu]

Hi Steve,

Basically, ConfigureAwait(false) return the context to the main thread once the task has finished. You need to use that if you are working on a UI however, there is a workaround on this, don’t block on Tasks; use async all the way down.

http://blog.stephencleary.com/2012/07/dont-block-on-async-code.html

[steve-tapley]

Hi,

Thanks for your response - I've read Stephen's articles many times :) In all my experiences so far with async/await if I dont use ConfigureAwait(false), then one of my scenarios will not work (I call this particular code from a WebAPI as well as a console application). I still consider myself a relative newbie at async/await though. :)

Anyway, IMHO, the library is broken unless it provides the ability to do this. I'm not willing to risk my webapp (or console app) locking up. (I know you're not the author here, but if I cant find an easy solution, then I'll simply go back to the older version).

Cheers,
Steve

[xt0rted]

You're better off sticking with the older version since it's not dynamic. It'll make this a lot easier for you.

The fact that you have to do this with the older version means it's also broken. The library is supposed to call .ConfigureAwait(false) every time it awaits something (which it's not). Doing so should prevent you from having to deal with this when you call in to it.

[thinkingserious]

@steve-tapley,

Thanks for reaching out! Maybe this thread can help you? #259

@M3LiNdRu,

Thanks for attempting to help!

@steve-tapley @xt0rted,

A version of this library (v9) that does not have the dynamic dependency is in development. You can follow along here: https://github.com/sendgrid/sendgrid-csharp/projects/4

I'm going to leave this ticket open until this issue is confirmed to be resolved.

[steve-tapley]

@thinkingserious

Thanks for that. I've made the decision to revert back to 6.3.4 and wait until v9 comes out. As long as it follows async/await conventions and isnt dynamic, then I'll be happy.

Cheers,
Steve

[thinkingserious]

@steve-tapley,

Indeed, we will be checking off your wish list :)

Thank you for your patience.

[Jericho]

@steve-tapley in case you don't want to wait for v9, I have released a library that is completely Async, strongly typed (no dynamic at all), compatible with both .Net 4.5.2 and .Net Core, and covers not only the "email" resource but also all other resource of the SendGrid API (such as list management, contacts bulk import, creating segments, retrieving statistics, etc.).

[iampez]

@steve-tapley I'm reading this with interest as I am having trouble "waiting" on emails being sent through the SendGrid api (v6). I notice in your initial post you mentioned that this was the correct way to call the api to send an email:

var transportWeb = new Web(SendGridApiKey);
await transportWeb.DeliverAsync(emailMessage).ConfigureAwait(false);

As I understand it calling ConfigureAwait(false) will not prevent a deadlock (if I want to wait higher up the callstack), because the SendGrid api does not also call .ConfigureWait(false) in its awaitable calls (to HttpClient.SendAsync I think). Hence, they are blocking the SychronizationContext.

Does this make sense??? Essentially, I think what you have written is best practice (for awaitable calls), but the issue is the lack of ConfigureAwait(false) call in SendGrid api.

[thinkingserious]

@steve-tapley, @iampez,

v9 is now available. Please let me know if you run into any issues.