Adrian RomoAdrian Romo
Alle Texte
Tagesnotiz 1 Min. Lesezeit· caffeinated

Tägliche Notiz: Debugging eines Produktions-API-Workflows

Integrationstest grün, Staging grün, Produktion schlägt bei 1 % der Anrufer fehl. Der Fehler war an einem Ort, den ich nie vermutet hätte.

Heute war so ein Tag.

Die API gibt im Staging 200 zurück, 500 für ~1% des Produktionsverkehrs. CloudWatch zeigt, dass die Lambda nach 29,9s aussteigt. Jeder Integrationstest grün. Jeder Lasttest grün.

Habe zwei Stunden damit verbracht, die Datenbank zu beschuldigen. Es war nicht die Datenbank.

Es stellte sich heraus: Eine unserer upstream SaaS-Integrationen begann, Antworten mit einem spezifischen Header zurückzugeben, auf den unser HTTP-Client stillschweigend erneut versuchte. Drei Versuche × 10s Backoff = 30s = Lambda-Timeout. Die 1% waren die Teilmenge von Kunden, deren Daten zufällig über einen bestimmten Vendor-Edge geleitet wurden.

# vorher
session = requests.Session()
session.mount("https://", HTTPAdapter(max_retries=Retry(total=3, backoff_factor=1)))

# nachher
session = requests.Session()
session.mount("https://", HTTPAdapter(max_retries=Retry(
    total=3,
    backoff_factor=1,
    respect_retry_after_header=False,  # der Vendor lügt
    allowed_methods=frozenset(["GET"]),  # niemals POSTs erneut versuchen
)))
python

Lehre, die ich immer wieder lerne: Retry-Strategien sind eine Systemgrenze. Standardwerte sind fast immer falsch für dein System.

Gehe mit Kopfschmerzen, aber einem grünen Dashboard ins Bett.

Weiter geht's

Wohin als Nächstes?

Stöbere durch weitere technische Texte, sieh dir die Engineering Case Studies an oder melde dich direkt.