Une histoire confirmant l'implémentation de la bibliothèque Java SendGrid lorsque la livraison du courrier échoue

Préface

J'écris une application web en Java. J'utilise SendGrid pour livrer le courrier du système, mais si la livraison du courrier échoue pour une raison quelconque, après avoir supposé Puisque le traitement était de la mousse, je l'écrirai sous forme de mémorandum. ~~ Tout était une implémentation issue de la croyance du prédécesseur selon laquelle "une réponse renverra un résultat même en cas d'erreur". ~~

Créer un processus de remise de courrier à l'aide de SendGrid

Installez SendGrid Java Library dans build.gradle pour créer une méthode d'envoi d'e-mails. Si SendGrid renvoie une erreur dans les années 400, il ne sera pas retenté en raison d'un paramètre de demande incomplet envoyé à partir d'ici ou d'une demande en excès, laissant un journal et renvoyant les informations d'erreur au recto pour terminer le processus. Dans le cas de la série 500, il y a une erreur dans le serveur SendGrid, je l'ai donc créé pour réessayer 2-3 fois. Je vais omettre le code autour de la nouvelle tentative (désolé).

Référence: SendGrid: code d'état et erreur

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) {
            //La série 200 continue de traiter comme une transmission normale
      } else if (response.getStatusCode() < 500){
            //Une erreur de la série 400 est jugée que le paramètre de demande est invalide et le traitement se termine
            //Laisser un journal et renvoyer le message d'erreur au premier plan
      } else {
            //Une erreur de la série 500 est réessayée plusieurs fois en raison d'une erreur du serveur SendGrid
            //Gardez le journal
      }
    } catch (IOException ex) {
      throw ex;
    }
  }
}

Le problème que le traitement attendu n'est pas effectué

Je l'ai créé pour que le code d'état dans la réponse renvoyée comme ci-dessus soit jugé et que le traitement ultérieur soit distribué ~~ (prédécesseur) ~~. Il y a une faille dans le processus de vérification de validation lors de la rédaction d'un e-mail, le post-traitement n'est pas effectué lorsque l'e-mail ne peut pas être envoyé et le journal attendu ne reste pas, il s'avère donc que cette implémentation est défectueuse.

Vérifiez la mise en œuvre

Suivez la méthode api () de la classe com.sendgrid.SendGrid pour voir où vous envoyez réellement la demande à SendGrid. (Omis car vous pouvez l'atteindre en 3-4 étapes)


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());
	}
}

Vous pouvez voir que la classe com.sendgrid.Client a une méthode executeApiCall () qui exécute () sur la 3ème ligne, et surtout, l'instruction if sur la 6ème ligne lève une IOException. Même si le code d'état est supérieur à 300, vous pouvez remplir la réponse avec cette valeur et la renvoyer. .. ..

Valeur de retour SebdGrid, puis

Caused by: java.io.IOException: Request returned status Code 400Body:
{
    "errors": [
        {
            "message": "Invalid replyTo email address",
            "field": "reply_to",
            "help": null
        }
    ]
}

Puisque SendGrid renvoie un message d'erreur comme ci-dessus, j'aurais dû écrire le traitement suivant à partir de l'exception IOException capturée au lieu de la réponse. En outre, compte tenu du fait qu'il ne semble pas y avoir de panne à grande échelle dans SendGrid au cours des 1 à 2 dernières années et du taux d'utilisation du courrier, le processus de nouvelle tentative est supprimé et un message d'erreur s'affiche rapidement (le contrôle de validation a été corrigé). Donc l'erreur 400s ne devrait pas se produire!).

Sentiments divers

C'était un cas suspect où mes croyances et divers tests étaient inadéquats, mais j'ai appris à vérifier la valeur de retour de la bibliothèque utilisée et à l'utiliser.

Recommended Posts

Une histoire confirmant l'implémentation de la bibliothèque Java SendGrid lorsque la livraison du courrier échoue
[Java] Lors de l'écriture du source ... Mémorandum ①
[Édition Java] Histoire de la sérialisation
Une histoire sur l'utilisation de l'API League Of Legends avec JAVA
L'histoire de l'oubli de fermer un fichier en Java et de l'échec
L'histoire de la création d'un lanceur de jeu avec une fonction de chargement automatique [Java]
[Petite histoire Java] Surveiller lorsqu'une valeur est ajoutée à la liste
L'histoire de l'écriture de Java dans Emacs
L'histoire de la comparaison de chaînes de bas niveau en Java
L'histoire de la fabrication d'un Othello ordinaire à Java
Une histoire sur le JDK à l'ère de Java 11
L'histoire de l'apprentissage de Java dans la première programmation
Mesurer la taille d'un dossier avec Java
L'histoire de l'initialisation de Money :: Currency pendant les tests
Une histoire que les personnes qui ont fait iOS solidement peuvent être accro à la mise en œuvre de Listener lors du passage à Android
L'histoire de la création d'un proxy inverse avec ProxyServlet
Awesome Java: excellent logiciel de bibliothèque de framework Java
Une vue d'ensemble du framework Java natif de Kubernetes Quarkus
L'histoire de la création de DTO, semblable à Dao avec Java, SQLite
L'histoire de la création d'une version Java du serveur Minecraft avec GCP (et également de la création d'une liste blanche)
Une explication rapide des cinq types de statique Java
20190803_Java & k8s sur Azure L'histoire d'aller au festival
Une histoire remplie des bases de Spring Boot (résolu)
[Java] Simplifiez la mise en œuvre de la gestion de l'historique des données avec Reladomo
Implémentation d'un analyseur de syntaxe mathématique par méthode d'analyse syntaxique descendante récursive (Java)
Le piège que l'implémentation par défaut de l'interface Java 8 apporte
À propos du comportement lors de la création d'un mappage de fichiers avec Java
L'histoire de la transmission de Java à Heroku à l'aide du pipeline BitBucket
Comparaison des chaînes de version lorsque vous souhaitez brancher le traitement entre deux versions (implémentation Java)
Une histoire qui m'a fait regretter quand une "NotReadablePropertyException" s'est produite pendant le développement de l'application Spring Boot.