Produits Entr'ouvert » Passerelle

Dans les logs du connecteur, l'erreur indique (dans le payload) un numéro de transaction :

body     b'{"transaction_id": "bbd90fe0-eb83-11eb-bb4a-0213ad91a103", "transaction_date": "2021-07-23T07:02:11"}'
method     POST
exception     'NoneType' object is not subscriptable

La facture concernée :

{
   "data" : {
      "amount" : "2.6",
      "amount_paid" : "0",
      "created" : "2020-02-10",
      "display_id" : "319992",
      "has_pdf" : true,
      "id" : "16526-319992",
      "label" : "Facture unique - Janvier 2020",
      "online_payment" : true,
      "paid" : false,
      "pay_limit_date" : "2020-02-28",
      "total_amount" : "2.6",
      "vendor" : {
         "caluire-axel" : {
            "ECHEANCE" : "2020-02-28",
            "EMISSION" : "2020-02-10",
            "ENCAISSE" : "0",
            "EXISTEPDF" : true,
            "FACTURATION" : "Facture unique - Janvier 2020",
            "IDFACTURE" : 319992,
            "MONTANT" : "2.6" 
         }
      }
   },
   "err" : 0
}

Axel, qui nous présente cette facture à payer (via GETFACTURESAPAYER), nous renvoie un contenu vide (<PORTAIL/>).
Partant principe que le statut de la réponse est OK (<STATUS>OK</STATUS>) ce contenu aurait du se conformer au schéma R_SetPaiement.xsd et retourner code (0 Ok Négatif sinon dixit la doc).

<?xml version="1.0" encoding="UTF-8"?>
<PORTAILSERVICE>
  <RESULTAT>
    <TYPE>SetPaiement</TYPE>
    <STATUS>OK</STATUS>
    <DATE>23/07/2021 15:44:17</DATE>
    <COMMENTAIRES><![CDATA[]]></COMMENTAIRES>
  </RESULTAT>
  <DATA>
    <PORTAIL/>
  </DATA>
</PORTAILSERVICE>

Il faut mettre online_payment à False ou alors ne pas retourner la facture hors historique.

Il faut mettre online_payment à False

Désolé, je ne comprend pas.
Je reformule : Axel dit voilà ce qu'il faut payer, Lingo lui dit "voilà c'est fait" et Axel qui devrait dire "ok" ou "erreur" renvoie un message non conforme aux specs.

On est sur un crach du endpoit /caluire-axel/axel/regie/ENF/invoice/16526-319992/pay/
qui est appelé par lingo sans qu'ensuite aucune attention ne soit acordée contenu retourné.

regie.pay_invoice(item_id, self.order_id, self.bank_transaction_date or self.end_date)

Si l'on ne crash pas, alors l'appel ne sera plus retenté et la transaction ne sera plus vue comme orpheline (au sens de la note #3) alors que l'on ne sait pas si elle a bien été prise en compte ou non par le logiciel métier.

edit:
Désolé j'ai été embrouillé par https://dev.entrouvert.org/issues/55793#note-8 qui a plutôt rapport avec #55803.
Et donc oui, renvoyer une erreur qui donne du contexte plutôt que de crasher.

Je taperais plus large, façon

-        code = result.json_response['DATA']['PORTAIL']['SETPAIEMENT']['CODE']
+        try:
+            code = int(result.json_response['DATA']['PORTAIL']['SETPAIEMENT']['CODE'])
+        except (KeyError, ValueError):
+            raise APIError('Wrong pay-invoice response', err_code='pay-invoice-code-response-error')
+
         if code < 0:
             raise APIError('Wrong pay-invoice status', err_code='pay-invoice-code-error-%s' % code)

(de ton patch il y a aussi l'ajout d'une partie "data" à l'erreur, sur ce moment particulier, mais pas sur l'APIError qui peut être levée trois lignes plus bas, je n'ai pas repris ça dans mon exemple).

Oui pour ajouter du data pour avoir le contexte dans l'APIError, mais que va-t-il devenir (où va-t-on pouvoir le voir afin de comprendre la panne) ?

Par ailleurs sur le premier data, j'ajouterais "post_data": post_data, et j'appelerais kwargs avec son vrai nom "kwargs": kwargs au lieu de payload, qui pourrait laisser croire que c'est ce qu'on a envoyé à Axel.

Dans le second data, j'ajouterais "result": result.json_response pour voir ce qui ne va pas dedans

Nicolas Roche a écrit :

Pourtant, puisque la facture a bien été payée en ligne, je pense qu'il faut la rattacher à la main à la transaction pour qu'elle apparaisse en visuel ici :
https://ville-caluire.toodego.com/manage/lingo/?q=bbd90fe0-eb83-11eb-bb4a-0213ad91a103

Oui ça c'est un souci lingo, on ne crée le BasketItem lié à une facture que lorsque sont paiement a été notifié¹, on devrait le créer dès le retour de la banque, qu'on arrive pas à notifier l'application métier ça ne concerne pas l'usager.

Je viens de créer #55876 sur le sujet.