Salutare tuturor. Am dat de un zid destul de frustrant cu Prisma pe un proiect aflat în producție de vreo șase luni și am zis să cer o a doua opinie aici, înainte să-mi pierd complet mințile sau să rescriu totul în SQL chior.
Avem un API în NestJS, cu PostgreSQL pe AWS RDS (o instanță destul de decentă, db.t4g.medium) și Prisma ca ORM. Proiectul are în jur de 12k utilizatori activi zilnic, nimic astronomic, dar destul cât să vedem niște load real în orele de vârf. Problema e simplă și extrem de enervantă: din când în când, complet aleatoriu, ne trezim în loguri cu eroarea asta: PrismaClientKnownRequestError: Transaction already closed: Transaction is no longer valid. Last state: Expired.
Partea cea mai proastă? Nu se reproduce niciodată pe local sau pe staging. Apare doar în prod, de vreo 10-15 ori pe zi, de obicei când crește traficul pe zona de checkout, unde facem mai multe scrieri dependente de un flow de plată.
Uite ce am încercat până acum, ca să nu reluăm aceleași sfaturi de bază:
1. Am mărit timeout-urile la maximum
Știam că Prisma are un timeout implicit destul de agresiv pentru tranzacții interactive (parcă 2 secunde pentru maxWait și 5 secunde pentru timeout-ul propriu-zis). Am crescut valorile astea progresiv. Acum suntem la maxWait: 15000 (15 secunde) și timeout: 20000 (20 de secunde). Teoretic, e un timp enorm pentru niște query-uri simple. Cu toate astea, eroarea continuă să apară exact în același ritm.
2. Am curățat tranzacțiile de orice I/O extern
La început, recunosc, am făcut greșeala clasică. Aveam un apel de API extern (către procesatorul de plăți) chiar în interiorul blocului prisma.$transaction. Am zis: „gata, asta e!”. Serviciul extern răspundea greu, tranzacția expira și de acolo venea eroarea. Am refactorizat tot. Acum, în tranzacție avem doar query-uri SQL curate: citire user, creare comandă, decrementat stoc, inserat log. Totul durează sub 50ms pe ceas. Eroarea încă apare.
3. Configurația de connection pooling și resurse DB
Am verificat metricile din AWS. CPU-ul pe RDS nu trece de 30% în momentele de vârf, iar conexiunile active sunt pe la jumătate din limita maximă a bazei de date. În connection string-ul de Prisma avem connection_limit=20. Am încercat și cu PgBouncer în modul session, dar comportamentul este identic.
Trade-off-ul pe care îl simt acum
Prisma e excelent pentru rapiditatea cu care livrezi features. DX-ul e genial, tipizarea te scapă de multe bătăi de cap, dar când vine vorba de debugging profund, motorul lor scris în Rust e o cutie neagră. Când crapă ceva acolo, logurile de Node sunt aproape inutile. Îți vine să arunci laptopul pe geam când vezi doar un stack trace generic care îți zice că tranzacția a expirat, fără să-ți dea cel mai mic indiciu de ce query engine-ul a decis să o închidă prematur.
A mai lovit cineva problema asta în producție? Să fie o problemă de event loop block în Node care întârzie execuția query-urilor interne, sau e ceva dubios în engine-ul lor de Rust pe partea de conexiuni?