-
Notifications
You must be signed in to change notification settings - Fork 587
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Missing ConfigureAwait(false) on async calls #198
Comments
I agree. Just caught this because it resulted in deadlock in my application. |
I have forked SendGrid's repo and added several improvements such as ability to inject httpclient for unit testing, meaningful method names (as opposed to simply 'get', 'post', 'patch', etc.), strongly typed return values from methods, etc. Also, all methods are awaitable and ConfigAwait(false) is specified on every async call. You can find my fork here: https://github.com/Jericho/sendgrid-csharp |
Hello @roryprimrose, @samrueby and @Jericho, We are in the process of releasing a new version of this library that supports all of our Web API v3 endpoints. It will be a breaking change and we are hopeful the release will happen within a few months. The general idea is to provide a solid core that has as few third party dependencies as possible. Using this core, we will build helper functions and workflows to complete specific tasks on top of the core. To start, we have ripped out the client into it's own repo (the new library will only have this repo and maybe our smtpapi client as dependencies), any feedback you may have is appreciated: https://github.com/sendgrid/csharp-http-client For reference, the new library will be similar to https://github.com/sendgrid/sendgrid-python; however, there are few key things still missing in that library:
Thanks for your continued support! |
@Jericho - DUDE!!! This is awesome. |
All - RE: Elmer's message: This allows us to continue the work you're doing, while merging it with our own -- after we have your feedback on the client, of course! |
Hello everyone, the new version of this library is available in beta here: https://github.com/sendgrid/sendgrid-csharp/tree/v3beta I'm leaving this ticket open for evaluation against the new library. |
Hi, The workaround described in the readme
isn't a particularly great solution either. Can I suggest that if the V3 is some time off, then this bug gets some attention? Thanks, |
Hello @steve-tapley, We are a few weeks away from leaving beta and we have shifted all our open source resources to support the v3beta branch and the new v3 /mail/send endpoint: https://sendgrid.com/docs/API_Reference/Web_API_v3/Mail/index.html I don't anticipate any major changes to the v3beta branch before launch, mostly the changes will be under the hood. The biggest change will be moving the endpoint from /mail/send/beta to /mail/send. With Best Regards, Elmer |
@roryprimrose @samrueby @Jericho @steve-tapley This issue is now fixed, per: #235 The same offer regarding swag we made on issue 255 applies to all of you here. Especially @roryprimrose for providing the solution and @Jericho for implementing! :) Now that we are out of beta, we are going to be looking at the next milestone for this library. We have much to do and we need help with prioritizing. If there are any features/issues that you want given attention, please open an issue or +1 existing issues. We will read and consider them all. Currently, we plan to make the enhancements through Helpers: https://github.com/sendgrid/sendgrid-csharp/tree/master/SendGrid/SendGrid/Helpers and Mail was the first example. The next goals (tentative) for that Helper is to add library side validation, nice error handling and helper functions to mask away complexity and make common use cases easy. We are thinking the next area of Helpers might be templates, contactdb and perhaps subuser management. Thanks for your continued support! All feedback is welcome! |
I there, I'm looking at migrating to SendGrid and was browsing through the C# support. I noticed you are using async/await (great!) but that the calls did not use .ConfigureAwait(false). This is going to cause unnecessary thread context synchronization. Can you please add ConfigureAwait calls into all the await executions.
The text was updated successfully, but these errors were encountered: