Spring til indhold

Har implementeret validering af mailudbyder ved opstart på tværs af tre udbydere (SendGrid, SMTP2GO, Azure ACS) med miljøbevidst adfærd — logning i udvikling, fejl ved opstart i staging og produktion.

Backend‑udvikler

Situation. E‑mail vejer tungt på NextMariner — verificering, notifikationer, de ting en bruger faktisk venter på. Og en mailudbyder er præcis den slags afhængighed, der fejler lydløst: konfigurationen ser fin ud, appen booter, og du opdager først, at noget er galt, når et rigtigt menneske aldrig får den besked, det blev lovet. Det er den værste måde at få det at vide på.

Opgave. Appen skulle ved opstart tjekke, at mail rent faktisk virkede, og være højlydt om det i de miljøer, hvor det betyder noget, uden at gøre en rutinemæssig lokal kørsel til en plage.

Handling. Så udbyder‑validering gik ind i boot‑sekvensen, bag et MAIL_VALIDATE_ON_START‑flag. Den sender en rigtig test gennem udbyder‑stakken — SendGrid som primær, med SMTP2GO og Azure Communication Services bagved som fallbacks — og hvordan den reagerer afhænger af, hvor den kører. I develop logger den bare en advarsel og fortsætter; ingen vil have deres laptop til at nægte at starte, fordi en sandkasse‑nøgle er udløbet. I staging og produktion er en fejl fatal: processen afslutter frem for at deploye et build, der ikke kan sende mail. Selve afsendelsen går gennem en SSRF‑beskyttet klient med et 30‑sekunders timeout, og den asynkrone leveringssti har sine egne retries og backoff, så et øjebliks udfald ikke taber en besked.

Resultat. En hel kategori af lydløs fejl flyttede fra “en bruger opdager det dage senere” til “deployet stopper.” Hvor brudt mail er et reelt problem, kan det ikke slippe igennem; på en udviklers maskine holder det sig ude af vejen. Samme tjek, forskellig lydstyrke afhængigt af hvem der kigger med.