commandes en double #46
Comments
|
Bonjour, moi aussi, mais depuis quelques jours seulement, et sans avoir touché au site. OVH mutu - PS 1.6.1.1 - TGGATOS v3.1.0 (Mercanet) |
|
idem, je n'ai rien touché et ça arrive depuis quelques jours également. PS 1.6.1.4 (dernière version) - ça marchait parfaitement avant. |
|
Ca sent le petit changement coté bancaire/ATOS. Perso je n'ai reçu aucun avertissement de leur part (même jamais rien). Je suis certain que TGG va nous tirer ça au clair. |
|
Hello,
Pas si sur, j'ai rejoint la start up française LiveMon en fin d'année dernière et cela me laisse peut de temps pour jouer avec PrestaShop. @nicolain06 Quelle banque ? Quelle version du module ? @nicolain06 @tucoinfo Vos doublons sont-ils liés tous deux au même ID panier ou le panier est-il lui aussi dupliqué ? step 1Vérifiez les response logs du module pour regarder si les réponses relatives à ces commandes sont présentes en double aussi. Le module vérifie que le panier n'est pas déjà associé à une commande avant de traiter la réponse bancaire, mais comme le reste de PrestaShop ce module n'utilise pas de transactions SQL => une race condition reste possible, dans certains cas de forte charge j'ai pu observer des serveurs SIPS envoyant des séquences de validation de commande incohérentes (souvent une réponse de transaction annulée + une réponse de transaction confirmée). step 2Vérifier si ces commandes contenaient un ou plusieurs produits en rupture de stock : cette partie du code de PrestaShop est bien connu pour avoir provoqué de nombreuses anomalies sur les commandes (commandes sans statut, commandes corrompues, commandes avec séquence de statuts incohérente...). step 3Pourriez-vous lister tous les deux les modules greffés sur les hooks de validation de commande et de changement de statut de commande voir s'il y a là un point commun suspect ? |
|
Salut Damien,
Oui, liés au même ID panier, oui le panier est visiblement dupliqué avec 2 IDs différents.
Oui, le .log montre des doublons : même transaction_id, même order_id, tout pareil sauf customer_email et customer_ip_address qui sont vides dans le 2ème.
Peut pas conclure de mon coté. Une commande avec alerte mail de rupture mais pas encore vraiment le cas (juste en dessous du seuil d'alerte).
Je ne sais pas si c'est tout ceci mais voici : |
Comment cela ? le doublon ne peut pas à la fois être lié au même ID panier et à l'ID un panier dupliqué. Oui, le .log montre des doublons : même transaction_id, même order_id, tout pareil sauf customer_email et customer_ip_address qui sont vides dans le 2ème.
Quid du return_context ? Si l'une des deux réponses est la réponse silencieuse, l'autre le retour utilisateur alors il s'agit d'une cinématique normale. |
|
Banque SMC, version 4.0.0 du module. J'ai bien les entrées en double dans le log, ainsi que dans la base de données. Le id_cart est le même sur les deux enregistrements (voir PJ des logs & bdd) Step 2 : aucune commande contenant des produits en rupture Step 3 :
|
ID panier A = ID order X
Je ne sais pas trop, mes entrées return_context ont toujours était non renseigné selon le log. |
|
PS : même soucis depuis quelques jours sur un autre prestashop complètement séparé avec le module v3.3.1 |
Oups je vois ça moi aussi sur un autre site PS 1.6.0.14 / TGGATOS 3.4.0 et là il n'y a vraiment aucun souci de puissance (SD optimisé). |
|
Même problème sur Prestashop 1.6.0.6 et le module TGG 4.0.0 avec Sherlocks LCL.
|
|
Ce ne sont pas des doublons : une response_type user et une silent correspondent au workflow standard. Le problème semble venir d'une race condition à débusquer dans Lorsque plusieurs personnes se mettent subitement à avoir un problème de timing sur des versions différentes, il faut généralement rechercher quel est le webservice commun dont les latences ont récemment augmenté. |
|
PS: il vaut mieux désactiver temporairement le mode NO_RESPONSE_PAGE qui renforce les risques de déclancher cette race condition en diminuant fortement le délai entre les réponses silencieuses et retour utilisateur. Je vois une manière de résoudre ce problème de race condition interne à PrestaShop depuis le module via une page de mise en attente avec ping ajax et une table de verrou sur les ID paniers, mais cela représente un temps de développement substantiel dont je ne dispose pas actuellement. |
|
ERRATUM La race condition n'était auparavant pas possible grâce à cette mise en attente de la fin de réponse silencieuse, cette mise en attente a du être retirée par SIPS, il faut les contacter à ce sujet (je n'ai personnellement aucun contrat VAD et donc aucun accès support auprès de SIPS ou d'une banque exploitant SIPS). |
|
Je vais les contacter et plus on sera nombreux plus on aura de réponses. |
|
Un workaround temporaire bien immonde pourra être simplement d'ajouter un sleep() ou usleep() sur le controlleur userreturn donnant un délai suffisant (le délai nécessaire dépendant des performances de la boutique, 200ms devraient suffire pour une boutique rapide, jusqu'à 2s pour les plus lentes) à la réponse silencieuse pour enregistrer la commande en BdD avant que la réponse utilisateur ne commence son traitement. Si quelqu'un a un peu de temps pour coder, il faudrait implémenter une table de verrou sur l'ID panier et mettre l'utilisateur en attente tant que le verrou est en place. Ou implémenter les transactions avec rollback. |
Oui, avec SIPS il faut monter au créneau en masse, si un seul utilisateur a un problème, ce n'est pas leur problème. |
|
Bonjour, |
|
Réponse Mercanet :
|
|
par rapport à l'idée de faire un "quick fix", où verriez-vous le sleep? quel fichier / fonction exactement ? |
|
@tucoinfo leur a tu bien expliqué que le problème venait du fait qu'ils ne mettent plus le client en attente que la réponse silencieuse soit terminée ? |
Ca oui mais je suis à 3 A/R déjà pour obtenir la confirmation. J'ai effectivement l'impression de parler à ma banque et non pas ATOS... |
|
Dernière réponse en date :
|
|
Thanks pour l'update Vous avez pu juguler vos doublons par l'ajout d'un délai ? Je sais c'est très moche comme méthode (il a fallu me faire violence pour la proposer) mais le rapport efficacité coût devrait être redoutable. |
|
J'ai testé avec un sleep(3) sur plusieurs boutiques différentes ayant le soucis, & j'ai toujours la commande en double... bien que décalée de 3 secondes. |
|
où le sleep a-t-il été ajouté ? |
|
sur userreturn.php (voir PJ)
|
|
étrange la réponse silencieuse devrait avoir largement le temps de créer la commande durant ces 3 secondes. Pourriez-vous me donner les heures dans les logs du module pour les deux réponses et les date_add des deux exemplaires de la commande ? |
|
Les voici
|
|
@mockassin La réponse silencieuse n'est pas 100% fiable, le traitement de la réponse utilisateur sert de fallback pour les cas où la banque échoue à envoyer la réponse silencieuse (il m'est arrivé d'avoir des journées où 25% des réponses silencieuses étaient en échec sur une boutique dont j'avais la maintenance). Vous pouvez désactiver le traitement de la réponse utilisateur si vous le désirez mais vous risquez de perdre des informations de paiement. |
|
D'ailleurs cela ne renforce pas réellement la sécurité non plus, car c'est l'encapsulation crypto des requêtes et réponses est le seul garant de la non manipulation des paiements. Le reste n'est que sparadraps. |
|
J'ai enfin pu prendre quelques heures pour m'installer un environnement de développement PrestaShop et ajouter une gestion de la concurrence au module pour la version 4.1.0. La version 4.1.0 utilise une table pour générer un lock sur un identifiant de panier. Cette page est très crue, si votre boutique est lente et risque donc de présenter cette page à l'utilisateur, customisez-la : https://github.com/TrogloGeek/prestashop-tggatos-module/blob/RC_4.1.0/views/templates/front/processing_payment_response.tpl Idéalement plutôt qu'une boucle d'attente PHP il faudrait présenter une page d'attente immédiatement et faire la boucle d'attente en polling ajax, mais je n'ai pas le temps pour une modification aussi lourde. Quelques personnes pourraient-elle tester la 4.1.0 et me faire des retours que je sache si je peux la basculer en version par défaut ? |
|
Bonjour Damien, merci de vos efforts. J'ai plusieurs v3.x dont une qui est encore sur PS1.4. Je peux plaquer les fichiers par dessus tout simplement ? |
|
Il vaudrait mieux utiliser GIT pour mettre à jour, il y a eu des fichiers renommés ou supprimés, et puis cela permet aussi de ne pas oublier une modification effectuée en local qui serait écrasée... |
|
Bonjour, |
Je ne sais pas si cela a été corrigé mais la dernière fois que j'ai eu le module officiel entre les mains (cela date de plusieurs années) son problème était justement de perdre des commandes en cas de défaillance d'une réponse. Je n'ai malheureusement pas de contrat VAD SIPS donc pas de certificat pour tester mes modifications. Si quelqu'un a un contrat (de préférence encore en pré-production) et peut me prêter le certificat pour faire des testes et corriger cela... |
Suis en prod mais je veux bien (mes doublons sont réduits mais il en reste). |
|
@fenaille tu peux encore améliorer en faisant |
|
Si vous avez pu accéder à un certificat et tester, tenez nous SVP au courant. |
|
Hello, j'ai enfin du temps et de l'énergie à consacrer à ce problème aujourd'hui et j'ai pu reproduire le problème avec la dernière version du module, donc je vais pouvoir travailler dessus \o/. La boucle d'attente fonctionne correctement, la persistance du problème vient que j'ai oublier de tenir compte du cache de Cart::orderExists() dont nous avons parlé précédemment. Je corrige ça. |
Purges Cart::orderExists() cache before processing user response.
|
J'ai enfin pu reproduire après avoir fixé (le problème côté SIPS est aléatoire, la plupart du temps le serveur bancaire me met correctement en attente de la fin de la réponse silencieuse avant de me rediriger). Le commit 4bff99d corrige le problème sur mes tests. |
|
@tranxene2000, @tucoinfo, avez-vous pu tester la dernière version ? |
|
Tout d'abord, merci (pour tous les sites concernés) de votre intervention. |
|
Merci Damien. Idem, RC4.1.1 tourne sur 3 sites peu actifs. Je passerai sur un dernier plus busy après quelques commandes réussies. |
|
Pas de nouvelles, bonne nouvelle ? |
|
Pour l'instant que de bonnes nouvelles sur 3 petits sites. Coincidence, j'ai eu un doublon PayPal après cette dernière mise à jour, certainement rien à voir puisque pas d'overrides si je ne m'abuse. Donc je vais upgrader un site plus important pour finaliser le test. |
|
Merci pour le retour @tucoinfo.
En effet, j'ai mis un point d'honneur en développant ce module a ne pas utiliser d'override du Core (ce qui m'aurait permis des fonctionnalités bien plus avancées et de simplifier certaines parties du code) car une méthode de paiement étant un connecteur terminal dans la plupart des cinématiques ne doit pas avoir d'influence sur le comportement de la boutique. (Sauf cas bien spécifiques, mais qui sont hors du cadre de la mission de ce module). Un des défauts inhérent à cette absence de verrou sur le panier pouvant être posé par une méthode de paiement est que l'utilisateur peut, via un second onglet, modifier le contenu du panier lorsqu'il est sur le serveur de paiement et que le montant a donc déjà été fixé. |
|
De mon côté une dizaine de commandes carte bancaire sans problème. Je redonnerai le feedback plus tard à nouveau pour dire la situation mais ça a l'air d'être résolu. |
|
Pas de quoi, on ne laisse pas trainer un logiciel défectueux dans la nature, surtout quand il s'agit d'un connecteur de paiement. |
|
Donc, sur le dernier des sites à upgrader on tourne également sans doublon depuis une bonne semaine maintenant. En ce qui me concerne c'est résolu. Merci Damien. |
|
Et merci à tous ceux qui m'ont fourni les informations dont j'avais besoin pour travailler sur le problème. |
|
Je confirme aussi. Ça tourne tjs sans doublons. Un grand merci. |
|
Bon,
Et vous me croyez ou pas, mais ces 2 urls sont appelées en fin de paiement. Et ces 2 urls créent des commandes.. // If the sealed is valid, we create the order / payment and redirect the customer
if ((bool)$is_sealed == true ) {
$error = true;
if($data['responseCode'] == "00"){
// Create Order / Payment "Ho ben tiens quelle bonne idée, si on créait une commande"
$notification = new MercanetNotification();
$notification->notify($raw_data, $params['Seal']);
$error=false;
}notification.php // If the sealed is valid, we create the order / payment and redirect the customer
if ((bool)$is_sealed == true) {
// Create Order / Payment
$notification = new MercanetNotification();//"Ho ben tiens quelle bonne idée, si on créait une commande"
$notification->notify($raw_data, $params['Seal']);
}Voilà voilà.... Alors en plus d'être des chêvres, il font du mauvais fromage... Si ma solution vous semble moisie, dites-le moi.... |
|
Bonjour, ce support concerne le module TggAtos, je peux difficilement gérer le support à la fois pour mon module gratuit et pour le module payant de PrestaShop auquel je ne suis aucunement lié. Mon module a été créé justement car je jugeais la stabilité et la qualité du module officiel largement insuffisant par rapport à mes standards de qualité concernant des transactions bancaires. La mise à jour 4.1.1 du module TggAtos corrige le problème auquel vous êtes confronté par l'utilisation d'un système de lock sur la génération de commande pour compenser la modification de fonctionnement du système de paiement SIPS en début d'année. Votre solution présente la problématique de ne pas avoir de solution de rattrapage dans le cas où la réponse automatique échoue (problématique que j'ai fréquemment rencontrée avec le système de paiement SIPS) auquel cas la commande n'est pas générée. Vous pouvez si vous le souhaiter tester et utiliser librement mon module qui est gratuit et libre, ou émettre une réclamation auprès du support de PrestaShop. |
|
Hello, |
Bonjour, certaines commandes sont doublées après réception du paiement : 2 commandes identiques sont insérées à la même seconde. Avez-vous déjà eu le soucis ? une idée pour le corriger ?
The text was updated successfully, but these errors were encountered: