Closed cmutel closed 6 months ago
The normal Stripe processing produces logs like this:
Apr 11 15:16:13 hubdds uwsgi[8588]: [pid: 8588|app: 0|req: 1288/1288] 127.0.0.1 () {58 vars in 1107 bytes} [Thu Apr 11 15:16:12 2024] POST /event/canada-2024/registration => generated 0 bytes in 444 msecs (HTTP/1.0 302) 8 headers in 253 bytes (1 switches on core 0) Apr 11 15:16:13 hubdds uwsgi[8588]: [pid: 8588|app: 0|req: 1289/1289] 127.0.0.1 () {52 vars in 974 bytes} [Thu Apr 11 15:16:13 2024] GET /payments/42/stripe => generated 7384 bytes in 531 msecs (HTTP/1.0 200) 8 headers in 358 bytes (1 switches on core 0) Apr 11 15:17:16 hubdds uwsgi[8588]: [pid: 8588|app: 0|req: 1290/1290] 127.0.0.1 () {50 vars in 1349 bytes} [Thu Apr 11 15:17:14 2024] GET /payments/42/stripe/success?payment_intent=XXX&payment_intent_client_secret=XXX&redirect_status=succeeded => generated 0 bytes in 1874 msecs (HTTP/1.0 302) 9 headers in 493 bytes (1 switches on core 0) Apr 11 15:17:16 hubdds uwsgi[8588]: [pid: 8588|app: 0|req: 1291/1291] 127.0.0.1 () {50 vars in 1195 bytes} [Thu Apr 11 15:17:16 2024] GET /profile => generated 8801 bytes in 107 msecs (HTTP/1.0 200) 9 headers in 456 bytes (1 switches on core 0) Apr 11 15:17:51 hubdds uwsgi[8588]: [pid: 8588|app: 0|req: 1292/1292] 127.0.0.1 () {52 vars in 1085 bytes} [Thu Apr 11 15:17:49 2024] GET /payments/42/download/receipt => generated 30768 bytes in 1994 msecs (HTTP/1.0 200) 8 headers in 282 bytes (1 switches on core 0)
The call to /payments/42/stripe/success gives a response code 302 redirecting to the profile page:
/payments/42/stripe/success
Apr 11 15:17:16 hubdds uwsgi[8588]: [pid: 8588|app: 0|req: 1290/1290] 127.0.0.1 () {50 vars in 1349 bytes} [Thu Apr 11 15:17:14 2024] GET /payments/42/stripe/success?payment_intent=XXX&payment_intent_client_secret=XXX&redirect_status=succeeded => generated 0 bytes in 1874 msecs (HTTP/1.0 302) 9 headers in 493 bytes (1 switches on core 0)
However, in the last two Stripe bookings we get something different:
Apr 14 11:41:09 hubdds uwsgi[8588]: [pid: 8588|app: 0|req: 1629/1629] 127.0.0.1 () {48 vars in 892 bytes} [Sun Apr 14 11:41:09 2024] GET /membership/apply => generated 10494 bytes in 59 msecs (HTTP/1.0 200) 8 headers in 359 bytes (1 switches on core 0) Apr 14 11:41:22 hubdds uwsgi[8588]: [pid: 8588|app: 0|req: 1630/1630] 127.0.0.1 () {54 vars in 1016 bytes} [Sun Apr 14 11:41:22 2024] POST /membership/apply => generated 0 bytes in 33 msecs (HTTP/1.0 302) 8 headers in 253 bytes (1 switches on core 0) Apr 14 11:41:22 hubdds uwsgi[8588]: [pid: 8588|app: 0|req: 1631/1631] 127.0.0.1 () {48 vars in 912 bytes} [Sun Apr 14 11:41:22 2024] GET /payments/46/stripe => generated 7412 bytes in 562 msecs (HTTP/1.0 200) 8 headers in 358 bytes (1 switches on core 0) Apr 14 11:41:41 hubdds uwsgi[8588]: [pid: 8588|app: 0|req: 1632/1632] 127.0.0.1 () {48 vars in 1328 bytes} [Sun Apr 14 11:41:39 2024] GET /payments/46/stripe/success?payment_intent=XXX&payment_intent_client_secret=XXX&redirect_status=succeeded => generated 145 bytes in 1740 msecs (HTTP/1.0 500) 8 headers in 465 bytes (1 switches on core 0) Apr 14 11:41:41 hubdds uwsgi[8588]: [pid: 8588|app: 0|req: 1633/1633] 127.0.0.1 () {48 vars in 1298 bytes} [Sun Apr 14 11:41:41 2024] GET /favicon.ico => generated 179 bytes in 2 msecs (HTTP/1.0 404) 6 headers in 214 bytes (1 switches on core 0) Apr 14 11:42:03 hubdds uwsgi[8588]: [pid: 8588|app: 0|req: 1634/1634] 127.0.0.1 () {48 vars in 1508 bytes} [Sun Apr 14 11:42:03 2024] GET /payments/46/stripe/success?payment_intent=XXX&payment_intent_client_secret=XXX&redirect_status=succeeded => generated 0 bytes in 6 msecs (HTTP/1.0 302) 9 headers in 518 bytes (1 switches on core 0) Apr 14 11:42:03 hubdds uwsgi[8588]: [pid: 8588|app: 0|req: 1635/1635] 127.0.0.1 () {48 vars in 1204 bytes} [Sun Apr 14 11:42:03 2024] GET /profile => generated 6848 bytes in 17 msecs (HTTP/1.0 200) 9 headers in 456 bytes (1 switches on core 0)
These last two payments are for membership instead of registration, maybe that is the broken pattern.
Easy fix, I am stupid: https://github.com/Depart-de-Sentier/dds_registration/blob/5c0f0d577928b8a1ebf588e576dc608e7986d760/dds_registration/views/billing_stripe.py#L83
cmutel
commented
6 months ago cmutel
commented
6 months ago
The normal Stripe processing produces logs like this:
The call to
/payments/42/stripe/successgives a response code 302 redirecting to the profile page:However, in the last two Stripe bookings we get something different:
These last two payments are for membership instead of registration, maybe that is the broken pattern.