Heroku tronque les réponses HTTP ?

Question

J'exécute un Flasque/Gunicorne Application Python sur un dyno Heroku Cedar. L'application renvoie JSON responses à ses clients (c'est un API server vraiment).

De temps en temps, les clients reçoivent des réponses à 0 octet. Mais ce n'est pas moi qui les renvoie. Voici un extrait du journal de mon application :

Mar 14 13:13:31 d.0b1adf0a-0597-4f5c-8901-dfe7cda9bce0 app[web.1] [2013-03-14 13:13:31 UTC] 10.104.41.136 apisrv - api_get_credits_balance() : session_token=[MASKED]

La première ligne ci-dessus est celle où je commence à traiter la demande.

Mar 14 13:13:31 d.0b1adf0a-0597-4f5c-8901-dfe7cda9bce0 app[web.1] [2013-03-14 13:13:31 UTC] 10.104.41.136 apisrv 1252148511 api_get_credits_balance() : renvoyant [{'credits_balance' : 0}]]

La deuxième ligne me permet de renvoyer une valeur (à Flask -- c'est un objet Flask "Response").

Mar 14 13:13:31 d.0b1adf0a-0597-4f5c-8901-dfe7cda9bce0 app[web.1] "10.104.41.136 - - [14/Mar/2013:13:13:31] "POST /get_credits_balance?session_token=MASKED HTTP/1.1" 200 22 "-" "Appcelerator Titanium/3.0.0.GA (iPhone/6.1.2 ; iPhone OS ; fr_US ;)"

La troisième ligne est celle de Gnicorn, où vous pouvez voir que Gunicorn a obtenu le statut 200 et un corps HTTP de 22 octets (" 200 22 ").

Cependant, le client a obtenu 0 octet. Voici le journal du routeur Heroku :

Mar 14 13:13:30 d.0b1adf0a-0597-4f5c-8901-dfe7cda9bce0 heroku[router] at=info method=POST path=/get_credits_balance?session_token=MASKED host=matchspot-apisrv.herokuapp.com fwd="66.87.116.128" dyno=web.1 queue=0 wait=0ms connect=1ms service=19ms status=200 bytes=0

Pourquoi Gunicorn renvoie-t-il 22 octets, mais Heroku voit 0, et renvoie effectivement 0 octet au client ? Est-ce un bug de Heroku ?

Answer 1

Je sais que l'on peut me considérer comme un peu à côté de la plaque, mais il existe une autre option.

Nous savons que, de temps en temps, un bogue survient pendant le transit et qu'il n'y a pas grand-chose que nous puissions faire pour résoudre ce problème. Si vous ne fournissez que l'API, arrêtez de lire, mais si vous écrivez aussi le client, continuez.

L'erreur est un cas connu, et une cause connue. Le résultat d'une valeur de retour vide signifie que quelque chose s'est mal passé. Cependant, la valeur est disponible et a été récupérée, calculée, etc... Mon instinct de développeur serait de traiter un résultat vide comme une erreur HTTP et de demander que les données soient renvoyées. Vous pourriez alors suivre les demandes de renvoi et voir combien de fois cela se produit.

Je vous suggère (bien que vous me paraissiez être le genre de développeur à penser à cela aussi) de compter les requêtes et de fixer une valeur raisonnable pour la réponse "erreur réseau" à l'utilisateur. Mon instinct me dit de réessayer tout de suite, puis d'attendre un peu avant de réessayer encore.

D'après ce que vous décrivez, la première tentative devrait probablement récupérer les données correctement. Bien entendu, cela pourrait signifier que les anciennes requêtes resteraient dans le cache pendant quelques minutes ou que la requête serait exécutée une seconde fois, selon ce qui semble le plus approprié.

Cela permettrait également de contourner un certain nombre d'autres erreurs de réseau point à point et de rendre l'application beaucoup plus robuste, même en cas de problèmes de connectivité.

Je sais que notre instinct de développeur nous pousse à réparer le défaut connu, mais il est parfois préférable de travailler à un système capable de fonctionner malgré les défauts. Cela dit, il n'est jamais inutile d'enregistrer les erreurs et les problèmes et d'essayer de les corriger de toute façon.