Dépannage

Les symptômes d’abord : chaque section liste les vérifications dans l’ordre qui résout le plus souvent le problème. Tous les exemples supposent les ports par défaut ; substituez les vôtres si vous les avez changés.

Connexion refusée

Le SDK ou curl n’atteint pas l’API HTTP. Soit le serveur ne tourne pas, soit il a démarré sur un --api-port personnalisé alors que le client pointe encore vers la valeur par défaut. Confirmez avec :

curl http://localhost:8025/health

Si vous avez changé --api-port, passez un baseUrl correspondant à InboxTapClient.

Port déjà utilisé

Le démarrage échoue quand un autre processus — souvent un InboxTap oublié — occupe déjà 1025 ou 8025. Trouvez-le avec lsof -i :1025, puis arrêtez-le, ou démarrez InboxTap ailleurs avec --smtp-port et --api-port. Quand les ports changent, mettez à jour à la fois les réglages SMTP de l’application et le baseUrl du client. Le serveur programmatique contourne entièrement le problème avec smtpPort: 0 et apiPort: 0.

Aucun email n'arrive

Vérifiez que l’application testée envoie vers l’hôte et le port qu’InboxTap a liés — un hôte SMTP de production resté dans un fichier d’environnement est la cause habituelle. L’autre cause fréquente est un système d’envoi configuré pour l’authentification ou TLS : InboxTap rejette volontairement AUTH et STARTTLS, configurez donc du SMTP simple non authentifié (pour Nodemailer, secure: false et pas de bloc auth). Voyez ce qui est réellement arrivé avec une liste non filtrée :

curl http://localhost:8025/api/emails

Les attentes expirent

Augmentez timeoutMs quand le parcours testé est réellement lent, mais restez à 60000 ou moins : le serveur plafonne une attente à 60 secondes et rejette les valeurs supérieures avec un 400. L’ordre n’est pas le problème — les méthodes d’attente balaient les messages déjà capturés avant d’interroger le serveur, il est donc sûr de déclencher l’email d’abord et d’attendre ensuite. Si l’attente expire encore, vérifiez le filtre : un subject chaîne correspond comme sous-chaîne insensible à la casse, une expression régulière correspond à son motif, et un filtre to doit correspondre exactement à l’adresse destinataire.

Les tests lisent les messages des autres

Appelez createInbox() dans chaque test pour que chacun attende sur une adresse destinataire unique. Une adresse partagée codée en dur fait que les processus parallèles consomment les messages des autres, et aucun vidage ne corrige cette course. inbox.clear() ne supprime que les messages de cette boîte, donc le nettoyage par test ne perturbe jamais un processus parallèle.

Les messages disparaissent

Le stockage est une FIFO bornée qui conserve les maxMessages plus récents (par défaut 100). Une suite parallèle chargée peut évincer un message entre l’envoi et l’assertion. Attendez la valeur immédiatement avec une méthode d’attente au lieu de lister plus tard, ou augmentez la limite avec --max-messages.

Message rejeté car trop volumineux

InboxTap répond SMTP 552 pour tout message dépassant maxMessageSize (par défaut 5242880 octets). Les grosses images intégrées sont généralement en cause. Augmentez la limite avec --max-message-size, ou allégez l’email — les pièces jointes sont de toute façon hors périmètre pour la v1.4.1.