Bug #48393
ObjectDoesNotExist
0%
Description
https://sentry.entrouvert.org/entrouvert/publik/issues/6267/
ObjectDoesNotExist: File "combo/apps/lingo/models.py", line 543, in notify_remote_items_of_payments remote_item = regie.get_invoice(user=self.user, invoice_id=item_id) File "combo/apps/lingo/models.py", line 216, in get_invoice raise ObjectDoesNotExist() unable to notify payment for remote item 180313-3690935 from transaction <Transaction: Transaction object>
Fichiers
Révisions associées
lingo: do not retry notify on 4xx error (#48393)
Historique
Mis à jour par Lauréline Guérin il y a plus de 3 ans
https://passerelle.eservices.toulouse-metropole.fr/manage/toulouse-axel/axel-famille/logs/?q=d27b869d-4db5-4431-ba9c-e039c062735a
=> la facture ne remonte pas dans le WS "factures à payer", on reçoit donc une APIError "Invoice not found"
https://passerelle.eservices.toulouse-metropole.fr/manage/toulouse-axel/axel-famille/logs/?log_level=&q=180313-3690935
=> on cherche à récupérer cette facture toutes les heures
Il s'agit d'un retry:
def hourly(self): self.update_transactions() self.notify_payments() def update_transactions(self): from .models import Transaction, EXPIRED logger = logging.getLogger(__name__) now = timezone.now() for transaction in Transaction.objects.filter( start_date__lt=now-datetime.timedelta(hours=1), end_date__isnull=True): logger.info('transaction %r is expired', transaction.order_id) transaction.status = EXPIRED transaction.save() for transaction in Transaction.objects.filter(to_be_paid_remote_items__isnull=False): transaction.retry_notify_remote_items_of_payments() # <= ici
Plusieurs pistes:
- pour une facture donnée, arrêter de retry au bout d'un temps raisonnablement long
- dans la méthode notify_remote_items_of_payments
, traiter autrement les 404 pour éviter de boucler dessus
- autre piste ?
Mis à jour par Benjamin Dauvergne il y a plus de 3 ans
Lauréline Guerin a écrit :
- pour une facture donnée, arrêter de retry au bout d'un temps raisonnablement long
Oui.
- dans la méthode
notify_remote_items_of_payments
, traiter autrement les 404 pour éviter de boucler dessus
Et oui aussi, on retry sur les 5xx sur les 4xx non (si on est raccorde avec le sens des codes HTTPs, une 4xx c'est un souci dans lingo, une 5xx c'est un souci dans passerelle). J'ai identifié le même souci sur une action manuelle de l'utilisateur pour supprimer un élément du panier, #48293.
Mis à jour par Lauréline Guérin il y a plus de 3 ans
temps raisonnablement long = quoi ? 15 jours ? plus ? moins ? j'en fais un setting ?
Mis à jour par Benjamin Dauvergne il y a plus de 3 ans
Lauréline Guerin a écrit :
temps raisonnablement long = quoi ? 15 jours ? plus ? moins ? j'en fais un setting ?
4 jours, si un truc déconne on devra l'avoir vu bien avant; là je nous donne un jour avant WE + 1 jours après, ça me parait suffisant. Logger en erreur sur une 4xx en warning sur une 5xx (on aura une erreur coté passerelle normalement).
On a une idée de pourquoi la facture a été visible un jour pour être payée et ne l'est plus maintenant ?
Mis à jour par Lauréline Guérin il y a plus de 3 ans
On a une idée de pourquoi la facture a été visible un jour pour être payée et ne l'est plus maintenant ?
Mon intuition: on a échoué sur la communication de la 2e etape (paid) - un timeout peut-être ?, et mis l'item de côté pour un retry.
Côté passerelle+axel, la facture a bien été marquée comme payée et remonte maintenant dans le endpoint historique.
Mis à jour par Lauréline Guérin il y a plus de 3 ans
- Fichier 0002-lingo-do-not-retry-notify-on-4xx-error-48393.patch 0002-lingo-do-not-retry-notify-on-4xx-error-48393.patch ajouté
- Fichier 0001-lingo-stop-retrying-notify-after-4-days-48393.patch 0001-lingo-stop-retrying-notify-after-4-days-48393.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Mis à jour par Benjamin Dauvergne il y a plus de 3 ans
Lauréline Guerin a écrit :
On a une idée de pourquoi la facture a été visible un jour pour être payée et ne l'est plus maintenant ?
Mon intuition: on a échoué sur la communication de la 2e etape (paid) - un timeout peut-être ?, et mis l'item de côté pour un retry.
Côté passerelle+axel, la facture a bien été marquée comme payée et remonte maintenant dans le endpoint historique.
Mais qui l'a marqué payé si ce n'est pas nous ? Ou alors la notification a abouti coté passerelle mais la connexion combo/passerelle a coupé avant que la réponse ne revienne.
Aussi je ne comprends pas pourquoi ça renvoie 404: est-ce qu'une facture payée disparaît du listing d'Axel ou bien c'est un traitement qui est fait dans le connecteur Axel ? Parce que ce qui aurait du arriver pour moi c'est "retry -> récupération de la facture -> si status=paid, ne pas notifier" mais ça suppose que la facture soit récupérable lorsqu'on retry, là elle a disparu un peu vite.
Mis à jour par Lauréline Guérin il y a plus de 3 ans
Ou alors la notification a abouti coté passerelle mais la connexion combo/passerelle a coupé avant que la réponse ne revienne.
Plutôt ça oui.
Je voudrais bien vérifier dans les logs mais il va falloir attendre la prochaine mep (et les opti sur les pages de log) pour accéder à:
https://passerelle.eservices.toulouse-metropole.fr/manage/toulouse-axel/axel-famille/logs/?log_level=&q=180313-3690935
une facture payée disparaît du listing d'Axel
Oui, il y a 2 WS côté Axel: liste des factures à payer, liste des factures déjà payées.
Si une facture est payée elle sort des résultats du premier pour apparaître dans le second.
Le status qui est checké c'est Transaction.status côté lingo, pas ce qui est renvoyé par Axel. D'après le code on marque d'abord Transaction.status à paid puis on fait un notify, qui peut échouer et partir en retry.
Mis à jour par Benjamin Dauvergne il y a plus de 3 ans
- Statut changé de Solution proposée à Solution validée
Lauréline Guerin a écrit :
Oui, il y a 2 WS côté Axel: liste des factures à payer, liste des factures déjà payées.
Si une facture est payée elle sort des résultats du premier pour apparaître dans le second.
Ok, je pense que ce serait bien que si la facture n'est pas trouvée dans les factures à payer que ça essaye dans l'historique (mais ça n'est pas le bon ticket pour ça); après vraisemblablement que ça plantera sur une double notif dans Axel à moins que le cas soit géré.
Mis à jour par Lauréline Guérin il y a plus de 3 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit 870238eb4129a082f9de313840aa55b66c89bffb Author: Lauréline Guérin <zebuline@entrouvert.com> Date: Mon Nov 23 15:48:28 2020 +0100 lingo: do not retry notify on 4xx error (#48393) commit 8b749e4cfbabe3b7ad12715fc93c7ae1bf30feca Author: Lauréline Guérin <zebuline@entrouvert.com> Date: Mon Nov 23 10:12:49 2020 +0100 lingo: stop retrying notify after 4 days (#48393)
Mis à jour par Frédéric Péters il y a plus de 3 ans
- Statut changé de Résolu (à déployer) à Solution déployée
lingo: stop retrying notify after 4 days (#48393)