Project

General

Profile

Bug #90074

toulouse-maelis: date de notification à maélis non positionnée

Added by Nicolas Roche about 2 months ago. Updated 8 days ago.

Status:
Solution déployée
Priority:
Normal
Target version:
-
Start date:
26 April 2024
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No

Description

Sur une erreur 502 du proxy (la PFS à Toulouse)
https://sentry.entrouvert.org/entrouvert/publik/issues/122809/?referrer=RegressionActivityEmail
le connecteur se mange une SOAPFault et décide d'arrêter là la notification à Maélis (dans les faits il semblerait que la notification soit bien reçue, que ce soit sa réponse qui ne parvienne pas au connecteur).

fails to notify paid invoice <Invoice "102/50996"> (...), stopping.

Pour cela il enregistre une date de notification,

        obj.maelis_notification_date = now()
        obj.maelis_notification_data = result
        obj.save()

afin que le cron qui passe derrière ne renvoie pas la notification.

> con.invoice_set.filter(maelis_notification_date__isnull=True, lingo_notification_date__lt=now() - datetime.timedelta(minutes=15))
<QuerySet [<Invoice "102/50996">]>

Sauf que régulièrement, ces 2 champs ne sont pas renseignés (champs mis à jours depuis, par le cron).

> con.invoice_set.get(regie_id=102, invoice_id=50996).__dict__
...
 'maelis_notification_data': None,
 'lingo_notification_date': datetime.datetime(2024, 4, 26, 8, 19, 9, 250411, tzinfo=<UTC>),
 'maelis_notification_date': None,

On a déjà identifié cette erreur mais sans réussir à l'expliquer.
https://dev.entrouvert.org/issues/85758#note-9

Le comportement n'est pas vraiment problématique, mais il génère de nouvelles erreurs sur le renvoie des notifications (déjà reçues pas Maélis) par cron qui sèment la confusion :
  • soit "E511 : Le montant du paiement ne correspond pas au solde des factures"
    parce que Maélis la sait payée et que de son point de vue il ne reste plus rien à solder.
  • ou, si l'envoi tarde un peu, l'erreur "E500 : Le montant est requis et ne peut être vide"
    parce que le connecteur à entre temps récupéré une mise à jour de la facture (puisque Maélis la sait payée) et tente de payer un montant nul.
      amount=str(Decimal(obj.maelis_data['amountInvoice']) - Decimal(obj.maelis_data['amountPaid'])
    

Ticket Sigec pour tenter de régler le problème en amont : ne pas avoir autant d'erreurs sur les notifications de factures payées.
https://redmine.sigec.fr/issues/4278

Associated revisions

Revision 4feba58e (diff)
Added by Nicolas Roche 8 days ago

toulouse-maelis: [test] SOAPFault on paid invoice notification (#90074)

Revision bc9d64d4 (diff)
Added by Nicolas Roche 8 days ago

toulouse_maelis: prevent concurrent update to same fields of Invoice (#90074)

History

#1

Updated by Robot Gitea about 2 months ago

  • Status changed from Nouveau to Solution proposée

Nicolas Roche (nroche) a ouvert une pull request sur Gitea concernant cette demande :

#2

Updated by Nicolas Roche about 2 months ago

  • Description updated (diff)
#3

Updated by Benjamin Dauvergne about 2 months ago

À me retourner la tête sur le sujet, vu qu'il est certain que la mise à jour de maelis_notification_date a bien lieu, c'est que l'effacement de ce champ vient d'une autre mise à jour. Invoice.notify() lock bien l'invoice avant de le mettre à jour mais il y a des tas de Invoice.save() ailleurs dans le code (notamment dans get_invoices()) qui ne le font pas.

Plusieurs possibilité pour corriger chacun de ces .save() :
  • remplacer les .save() par des .save(update_fields=...) et vérifier qu'il n'y a pas recouvrement avec d'autres mises à jour qui utiliserait un verrou pour mettre à jour les mêmes champs,
  • utiliser un verrou,
  • utiliser .objects.filter(pk=invoice.pk).update(...)

De forte chance que les coupables soient les 2 invoice.save() dans get_invoices().

#4

Updated by Robot Gitea about 2 months ago

  • Status changed from Solution proposée to En cours

Benjamin Dauvergne (bdauvergne) a relu et demandé des modifications sur une pull request sur Gitea concernant cette demande :

#5

Updated by Robot Gitea about 1 month ago

  • Status changed from En cours to Solution proposée

Nicolas Roche (nroche) a demandé une relecture de Benjamin Dauvergne (bdauvergne) sur une pull request sur Gitea concernant cette demande :

#6

Updated by Robot Gitea about 1 month ago

  • Status changed from Solution proposée to En cours

Benjamin Dauvergne (bdauvergne) a relu et demandé des modifications sur une pull request sur Gitea concernant cette demande :

#7

Updated by Robot Gitea about 1 month ago

  • Status changed from En cours to Solution proposée
  • Assignee changed from Nicolas Roche to Benjamin Dauvergne

Benjamin Dauvergne (bdauvergne) a ouvert une pull request sur Gitea concernant cette demande :

#8

Updated by Robot Gitea about 1 month ago

  • Status changed from Solution proposée to En cours

Benjamin Dauvergne (bdauvergne) a commencé à travailler sur une pull request sur Gitea concernant cette demande :

#9

Updated by Robot Gitea 14 days ago

  • Status changed from En cours to Solution proposée

Nicolas Roche (nroche) a demandé une relecture de Benjamin Dauvergne (bdauvergne) sur une pull request sur Gitea concernant cette demande :

#10

Updated by Robot Gitea 10 days ago

  • Status changed from Solution proposée to Solution validée

Benjamin Dauvergne (bdauvergne) a approuvé une pull request sur Gitea concernant cette demande :

#11

Updated by Robot Gitea 10 days ago

  • Status changed from Solution validée to En cours

Benjamin Dauvergne (bdauvergne) a fermé une pull request sur Gitea concernant cette demande.

#12

Updated by Benjamin Dauvergne 10 days ago

  • Status changed from En cours to Solution validée
#13

Updated by Robot Gitea 8 days ago

  • Status changed from Solution validée to Résolu (à déployer)

Nicolas Roche (nroche) a mergé une pull request sur Gitea concernant cette demande :

#14

Updated by Transition automatique 8 days ago

  • Status changed from Résolu (à déployer) to Solution déployée

Also available in: Atom PDF