-
Notifications
You must be signed in to change notification settings - Fork 583
Response contains HTTP code 200 and error in body if client sends an email when disconnected from Internet #358
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
Comments
Hi @chumakov-ilya, Thanks! We agree and I've added this to our backlog for a fix. |
I could look into submitting a pull request for this if the library maintainers are interested. |
Hello @ottomatic, A PR is always welcome :) We would just need a signed CLA to accept it. Thanks! With Best Regards, Elmer |
We've been having huge problems with this too. It's completely misleading. It shouldn't even be an HTTP response because it didn't even get that far. It's just a piece of c# code calling another piece of .net code and should get an appropriate exception. If it does have to be an HTTP response then @chumakov-ilya is correct it should be an error code. |
@jon64digital, Thanks for the feedback, we have added your vote to the issue. Are you still considering a PR? A few days ago we made the CLA process much easier. You no longer need to sign the CLA I linked to previously. When you make your PR, a link will be generated and all you need to do is click the link, fill out a few fields and then sign it by clicking a button. |
Yes, still intending to do this. One thing I would like to do in order to make unit testing easier is to take an HttpClient as an injected dependency in the SendGridAPIClient constructor. This would make it possible to inject a custom RequestHandler into the HttpClient, and in that way take control over the http response. What do you think of this change? |
Hello @ottomatic, I suggest you add a third constructor that allows for injecting the custom RequestHandler into the HttpClient. Thanks! Elmer |
@ottomatic If you want a "web-proxy-friendly" C# client for the SendGrid API with injectable HttpClient please have a look at StrongGrid (on github and on nuget). Also, while we are on the topic of mocking HttpClient calls, whether you decide to use StrongGrid or not I highly recommend you have a look at Richard Szalay's Mockhttp for HttpClient (on github and on nuget) which makes mocking HttpClient very easy. I have used it in a few unit testing projects to mock http calls and couldn't be more impressed. |
My apologies @ottomatic, I was thinking of another SDK. We do have support for Web Proxies in this library: https://github.com/sendgrid/sendgrid-csharp/blob/master/src/SendGrid/SendGridClient.cs#L45 Thanks for the suggestions on mocking HttpClient calls, very cool! |
@SendGridDX the constructor you pointed out does allow injecting I did a little research and found a PR submitted in June 2015 to allow httpclient to be injected but unfortunately it wasn't accepted. |
Thanks @Jericho! Does this point you in the right direction? If you have any further questions, please don't hesitate to reach out. |
Yes, the PR which @Jericho refers to is pretty much what I want to accomplish, and then use that to write a unit test in order to set up the throwing of an exception (e.g. a TimeoutException) when performing the httpclient call. I assume the PR was rejected because it was made against the wrong branch and did not comwe with a signed CLA? So, the easiest path forward for me is do do both the HttpClient injection and the exception handling (i.e. NOT swallowing the exception) in the same PR. Otherwise I will have to wait for one PR to be approved in order to be able to continue with the issue at hand. @SendGridDX , Is this approach acceptable? |
Thank sounds good @ottomatic, thanks! |
Allright. I have cloned the repo, and have successfully gotten started on the development. |
Quick update: I am swamped with work. The unit test is ready (and failing), so I should be able to complete the code as soon as I get a few minutes of spare time. |
In line with making this library more unit test friendly as @ottomatic has suggested. Would there be any interest in exposing an ISendGridClient etc that the existing classes implement? I for one would find it beneficial to be able to easily mock up a SendGridClient for my own unit tests, but cannot because none of the methods are virtual etc. My preferred mocking library is Moq, but as things stand I have had to go down the road of using Microsofts Fakes to make a ShimSendGridClient just so I can write tests for specific response codes being returned. |
@benmiller86 Your suggestion is already formalised in issue #403 and earlier in #201 . I think that would be a good idea and will upvote. |
OK, so the pull request has been submitted: This is my first PR ever! |
Issue #358: SendGridClient.SendEmailAsync now throws original exception
Hello Everyone, Thanks to @ottomatic, this issue is resolved in v9.1.1 via PR #434 |
Awesome, my pleasure. |
Hello @kirajhpang, I apologize, I don't quite understand the issue. Could you please provide the following details:
Thank you! Elmer |
This should have been fixed through the merge of PR #434 as per above. @kirajhpang, are you sure you have the latest version of the nuget package? (I have not tried it myself, so I cannot vouch that the new code has made it through the release pipeline). |
@thinkingserious Actually we facing this issue long time ago, since last time v2 api can't send out email. Some of the emails doesn't reach to 1. What are you expecting to happen? 2. Do you have access to the actual status code? (e.g. 202) 3. Can you share the source code? Thanks for the effort for building great tool. 😄 |
Hi @kirajhpang, Thanks for the follow up and please let me know how v9.2.0 works for you. With Best Regards, Elmer |
Uh oh!
There was an error while loading. Please reload this page.
Issue Summary
When I try to send an email without network connection to remote SMTP server, a response contains
200 OK
inStatusCode
andHttpRequestException
inBody
. I think it denies basic HTTP principles and such behaviour is completely unclear. I propose to throw a real exception. If impossible, the code from 4xx-5xx range should be used.Steps to Reproduce
Technical details:
The text was updated successfully, but these errors were encountered: