Remedierea erorilor critice la checkout și webhook-uri pe Magento 2 după actualizare - Stripe/PayPal - Redis/Varnish

După actualizarea Magento 2.4.6-p3 (PHP 8.2), producția magazinului online (B2C, ~15 mii SKU, 800-1200 comenzi/zi) a cunoscut eșecuri în plasarea comenzilor și desincronizare a plăților. Unii clienți primesc o eroare la pasul de plată sau comanda este creată fără tranzacție și uneori este duplicat. Jurnalele conțin un amestec de 500/502, timeout-uri, mesaje de blocaj MySQL și excepții în modulul personalizat de integrare ERP. De asemenea, am observat că uneori webhook-urile Stripe nu reușesc să confirme și PayPal IPN vine de două ori. Este necesar să se localizeze cauzele rădăcină și să corecteze erorile, astfel încât checkout-ul să funcționeze stabil sub sarcină.

Mediu tehnic: Magento Open Source 2.4.6-p3, Nginx, PHP-FPM 8.2, MySQL 8.0, Redis (sesiuni+cache), Varnish, Elasticsearch/OpenSearch, RabbitMQ. Implementați prin GitLab CI, există staging, acces prin SSH. Există APM (New Relic) și jurnalele centralizate (ELK). Există mai multe module personalizate: integrare cu ERP (REST), logică promoțională, personalizare checkout. Plăți: Stripe (PaymentIntents + webhooks) și PayPal.

Rezultat așteptat: cauzele remediate ale erorilor de plată, procesarea corectă a webhook-urilor/notificărilor, lipsa dublării comenzilor/tranzacțiilor, funcționarea stabilă sub încărcare. Este necesar un set de modificări de cod și configurare, plus un scurt raport tehnic despre ceea ce a fost defect și cum a fost testat.

Restricții: oprirea producției este interzisă, este permisă doar o scurtă fereastră de lansare de 10-15 minute. Modificările trebuie să fie compatibile cu modulele personalizate actuale. Nu puteți dezactiva Varnish/Redis în producție, puteți face setări de puncte. Datele clienților nu pot fi încărcate în afara serverului.

Etape de lucru:
1) Diagnosticare: analiza jurnalelor (Magento/sistem/excepție, Nginx, PHP-FPM), urme New Relic, cron/coadă aferente, redare pe scenă cu profiler activat, căutarea condițiilor de cursă în ordinea locului, verificarea idempotității pentru Stripe/PayPal.
2) Remedieri: editări în modulul personalizat de checkout/ERP (tranzacție, reîncercare, blocare/chei unice), corectare procesare webhook-uri (semnătură, repetări, ordinea evenimentelor, cheie idempotity), eliminarea cauzelor blocajului (indexuri/ordinea înregistrărilor), timeout-uri/setări fastcgi, optimizarea SQL/consumer slow specific.
3) Validare: testare de încărcare pe staging (k6/JMeter) pentru scenarii de checkout 3DS/non-3DS, simularea webhook-urilor repetate, verificarea neduplicării, regresia codurilor promoționale/livrare/taxe.
4) Lansare: pregătire MR, instrucțiuni de implementare, plan de rollback, asistență pentru lansare și monitorizare 24 de ore.

Criterii de acceptare (măsurate):
- La punerea în scenă cu 50 de utilizatori virtuali, checkout-ul are o rată de succes de cel puțin 99% într-un test de 30 de minute fără 500/502 la pasul de plată.
- În producție în 24 de ore de la lansare: ponderea erorilor de comandă de plasare <0,2% (conform New Relic), nu există comenzi duplicate cu același payment_intent_id/PayPal txn_id.
- Webhook-urile Stripe sunt procesate cu confirmare 2xx 99,9% din timp, evenimentele repetate nu creează noi facturi/livrări.
- Depozitul are un MR cu o descriere a modificărilor și un scurt raport (1-2 pagini) cu cauzele principale și link-uri către jurnalele/metrice.

Voi oferi acces și materiale: SSH la staging/prod, acces la GitLab, New Relic, exemple de ID-uri de comandă/plată problematice, ferestre de timp incidente.