Jump to content

Validation commande - Problème aléatoire


Antho

Recommended Posts

Configuration :
- Prestashop Version 1.0.0.8
- Module de paiement BNP Paribas Atos (Cyberplus) v1.2
- Serveur mutualisé OVH 720 plan

Problème :
Le problème se situe lors de la validation d’une commande (retour banque). Malgré le succès de la transaction, l’enregistrement de ma commande dans la table « order_detail » ne se réalise pas lorsque le panier dépasse 5 ou 6 produits, ainsi le dernier panier et le total de ma commande est bien enregistré mais la somme des prix produits affiche 0 €. Aucun message d’erreur ne s’affiche durant la procédure… Pourquoi à ce compte la les « petites » commandes (3/4 produits) fonctionnent-elles ?

Exemple (cf image)

Plusieurs pistes à éclairer :
- Erreur SQL dû au serveur ? c'est-à-dire trop de produit donc trop grosse requête ? (Or d’après OVH aucun souci de surcharge sur le serveur…)
- J’ai reproduit ce problème avec le paiement par chèque avec des erreurs provenant du module « Alertes email », ce module peut-il être la source du problème ? sans ces erreurs toutes les commandes fonctionnent (sur le même serveur)
- Une erreur ce glisse lors d’un retour de la banque ?

Donc un appel à l’aide pour ceux qui auraient une idée…
Merci !

3089_BOd6aqoY2tnzQznvEOlh_t

Link to comment
Share on other sites

Si tu as acheté un module chez Prestashop et qu'il ne te donne pas entierement satisfaction je pense que tu peux demander à Prestashop de régler le probleme pour parfaire leur prestation, à moins que tu n'ai fait des modifications du module.

Link to comment
Share on other sites

Je n'ai pas touché au module. Là j'ai obtenu un certificat de démo auprès de la banque que je vais installer sur un autre serveur (avec l'aide de presta, je l'espère) pour faire encore et toujours des tests... Je vous tiens au jus.

Link to comment
Share on other sites

En effet, comme le dit Jolvil nous sommes toujours de bonne volonté pour aider.

Ma théorie est que le module mail alert a planté car il n'y avait pas les droits nécessaire sur votre template.
Etant donné que ce module est appelé juste avant le remplissage de order_detail vous avez la commande mais son contenu.

Solution : désinstaller mail alert, mettre les droits, le réinstaller

Ce bug a déjà été soulevé à de nombreuses reprises, je pense qu'il s'agit de celui-ci.

Link to comment
Share on other sites

Effectivement cette théorie est valide mais pour mon cas ce n'est pas la source de mon problème (j'ai réinstallé le module mail alert, activé les droits, je reçois bien les mails "out ot stock", "new order" and co...).

Là je vais tracer les paramètres de la fonction validateOrder() de la class PaymentModule et voir ce qu'il se passe lorsque le problème ce passera à nouveau... Et tracer la mega requete (et son resultat) qui bascule les produits de la table cart à order_detail...
Je vous tiens toujours au courant ;)

Link to comment
Share on other sites

Alors je rentre bien dans la fonction validateOrder() et les paramètres sont bien existant, or aucune trace de la requête... ps_cart => ps_order_detail.
Donc le script de la fonction validateOrder() s'arrête entre temps

Link to comment
Share on other sites

Et tu as pu résoudre le problème ? tu penses qu'il pourrait venir de quoi ?

Aucune idée... Mais je serais étonné que ça vienne du module de paiement CB...
Pour le moment, le problème survient de façon très aléatoire. Je suis ça et j'essaie de comprendre le point commun entre toutes les commandes concernées.
Link to comment
Share on other sites

Alors je rentre bien dans la fonction validateOrder() et les paramètres sont bien existant, or aucune trace de la requête... ps_cart => ps_order_detail.
Donc le script de la fonction validateOrder() s'arrête entre temps

Qu'entendez-vous par aucune trace ?
La requête se situe à la ligne 133 et en-dessous :

/* Insert products from cart into order_detail table */

Celle-ci est stockée dans une variable $query, peut-être pouvez-vous faire un Tools::dieObject($query); afin de récupérer la requête, et la coller dans un phpMyAdmin afin de voir son résultat.
Link to comment
Share on other sites

En fait j'ai inséré une mail m'envoyant la variable $query juste après la mega boucle foreach à la ligne 176, si je comprends bien à ce stade la requête est construite et prête à être envoyée.
Or, le script s'arrête avant car je ne reçois aucun mail (je parle toujours pour les commandes supérieurs à 5 produits)
On envisage sérieusement de basculer le site sur un dédié.
Merci pour votre aide

Link to comment
Share on other sites

Si tu as acheté un module chez Prestashop et qu'il ne te donne pas entierement satisfaction je pense que tu peux demander à Prestashop de régler le probleme pour parfaire leur prestation, à moins que tu n'ai fait des modifications du module.


Bonjour,

Le module fonctionne correctement et nous l'installons régulièrement en quelques heures sans problèmes la plupart du temps.

Là le problème ne vient pas du module mais de la fonction Validateorder() qui pose problème sur cette version. D'autre part le tpe est déjà en production ce qui complique légèrement la possibilité de faire des tests.

Nous avons essayé de la debugger rapidement et le caractère aléatoire rend le debug difficile. Bruno, moi, Philippe, Rémi avons regardé et pour l'instant nous ne trouvons pas. A part un timeout du serveur pour l'instant pas trop de piste. Nous sommes dessus et ne laissons pas tomber tomber nos clients. A l'approche de Noël, vous comprendrez que nous avons aussi des impératifs de production qui ne nous permettent pas d'affecter la moitié de l'équipe sur d'autres tâches que celles prévues. Nous comprenons parfaitement les impératifs d'Anthony et allons faire notre maximum pour trouver pourquoi la boucle plante.
Link to comment
Share on other sites

Re bonjour,

Enfin de compte je pense que le serveur répond juste extrêmement lentement. On le voit à l'ajout de produit au panier qui fait bugger l'ajax d'ajout avec une belle erreur javascript. Si il perd sa connection avec mySql quand la requête est trop lourde il faudra effectivement revoir la partie hébergement. Le point commun avec Alibabike ne serait pas OVH ?

J'ai refait un test avec ma carte personnelle car le tpe est déjà en production (c'est juste le 3 ème client en deux jours ;-) ), avec 11 lignes de commandes et la commande est correctement passée. Coup de chance ?

Link to comment
Share on other sites

Merci pour votre réactivité !

Il est vrai que le site intègre beaucoup de produits, beaucoup de catégories, beaucoup de visites, et le tout sur un mutualisé ovh, donc les limites sont rapidement atteintes. C'est la seule raison plausible à ce jour...
Donc la prochaine étape est l'hébergement. Nous allons tester sur un dédié Kimsufi d'OVH.
Affaire à suivre... et encore merci pour l'aide de Prestashop !

Link to comment
Share on other sites

Toutefois, ce problème reste intéressant.

Cela veux dire que le script n'est pas adapté à des serveurs lents, et qu'il peut poser problème.
Il faut voir si une amélioration de l'algorithme ne peut pas être faite, afin de pouvoir satisfaire même les serveurs les plus lents.

Link to comment
Share on other sites

Oui, mais OVH reste un hébergeur extrêmement compliqué : il génère des erreurs 500 partout, dès qu'un problème minime se pose.

Du coup, cela empêche toute possibilité de tracer les problèmes.

La régénération des miniatures est un problème du même type (aléatoire, erreur 500, etc).
Et je n'ai toujours pas trouvé de parade à ce problème, car le traitement d'image "bouffe" énormément de ressource/temps d'exécution.

Tandis que la validation d'un panier en commande devrait être beaucoup plus simple à optimiser : il n'y a aucune tâche particulière, juste de l'insertion en base de données.

Link to comment
Share on other sites

Pour votre info il y a aussi un probleme avec la regeneration des miniatures qui ne fonctionne pas sur un mutualisé OVH, peut etre aussi la lenteur du serveur.


Oui bug déjà recensé, mais après il ne faut pas trop en demander au mutualisé, il faut se rendre à l'évidence que ce n'est pas fait pour ça !
Link to comment
Share on other sites

  • 1 month later...

salut à tous! des nouvelles pour ce problème?

j'ai effectivement un client pour lequel ça arrive de temps en temps, totalement aléatoire...
l'équipe presta si vous avez une idée?

que faut-il mettre à jour/patcher?

gracias :)

edit : pour moi ça tourne sur un dédié

Link to comment
Share on other sites

  • 2 weeks later...
  • 1 month later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...