I'm writing a web application in Java. I'm using SendGrid to deliver mail from the system, but if mail delivery fails for some reason, after assuming Since the processing was moss, I will write it as a memorandum. ~~ All were implementations that arose from the predecessor's belief that "Response will return results even in the event of an error." ~~
Install SendGrid Java Library in your project in build.gradle and create an email sending method. If SendGrid returns an error in the 400s, it will not be retried due to an inadequate request parameter sent from here or an excess request, leaving a log and returning error information to the front side to end the process. In the case of the 500 series, there is an error in the SendGrid server, so I created it to retry 2-3 times. I will omit the code around the retry (sorry).
Reference: SendGrid: Status Codes and Errors
dependencies {
compile ('com.sendgrid:sendgrid-java:4.0.1')
}
import com.sendgrid.*;
import java.io.IOException;
public class Example {
public static void main(String[] args) throws IOException {
SendGrid sg = new SendGrid(System.getenv("SENDGRID_API_KEY"));
try {
Request request = new Request();
request.setMethod(Method.GET);
request.setEndpoint("api_keys");
Response response = sg.api(request);
if (response.getStatusCode() < 300) {
//200 series continues processing as normal transmission
} else if (response.getStatusCode() < 500){
//For 400 series error, the request parameter is judged to be invalid and processing ends.
//Leave a log and return the error message to the front
} else {
//500s error is a SendGrid server error and retries several times
//Keep the log
}
} catch (IOException ex) {
throw ex;
}
}
}
I created it so that the status code in the response returned as above is judged and the subsequent processing is distributed ~~ (predecessor) ~~. There is a flaw in the validation check process when composing an email, post-processing is not performed when the email cannot be sent, and the expected log does not remain, so it turns out that this implementation is flawed.
Follow the api () method of the com.sendgrid.SendGrid class to see where you're actually sending your request to SendGrid. (Omitted because you can reach it in 3-4 steps)
private Response executeApiCall(HttpRequestBase httpPost) throws IOException {
try {
CloseableHttpResponse serverResponse = httpClient.execute(httpPost);
try {
Response response = getResponse(serverResponse);
if(response.getStatusCode() >= 300) {
//throwing IOException here to not break API behavior.
throw new IOException("Request returned status Code "+response.getStatusCode()+"Body:"+response.getBody());
}
return response;
} finally {
serverResponse.close();
}
} catch(ClientProtocolException e) {
throw new IOException(e.getMessage());
}
}
You can see that the com.sendgrid.Client class has an executeApiCall () method that executes () on the 3rd line, and above all, the if statement on the 6th line throws an IOException. Even if the status code is greater than 300, you can fill the response with that value and return it. .. ..
Caused by: java.io.IOException: Request returned status Code 400Body:
{
"errors": [
{
"message": "Invalid replyTo email address",
"field": "reply_to",
"help": null
}
]
}
SendGrid returns an error message as above, so I should have written the follow-on processing from the caught IOException instead of the response. In addition, in consideration of the fact that SendGrid is unlikely to have a large-scale failure for the past 1-2 years and the usage rate of emails, the retry process has been deleted and an error message has been displayed quickly (validation check has been fixed). So the 400s error shouldn't occur!).
It was a suspicious case where my beliefs and various tests were inadequate, but it was an event that I learned to check the return value of the library used and use it.
Recommended Posts