#csc_best-practices

1 messages ¡ Page 1 of 1 (latest)

half rockBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1340007671889395713

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

clear ridge
#

Hey! That's an excellent idea, but there is one potential issue, which is that if the request errors, retrying it like that would just return the failure.

What you could do is add a UUID to the Payment Intent's metadata, and add something like an attempt number to it?

#

What language are you writing in?

brazen wing
#

TypeScript, Node.js

clear ridge
#

How would you end up with two triggers to refund the same PI occurring in your system?

brazen wing
#

We have two ways refunds can be issued currently. We allow users to buy tickets to events, and if the event is canceled by the organizer, each payment associated with the event is refunded automatically. We also allow organizers to manually refund individual tickets. It's unlikely, but a manual refund might be issued when an automatic refund is processing, after the automatic refund is created but before the payment record in our database has its status updated.

The automatic refunds are processed in background jobs with automatic retry logic as well. It's possible that one of those refund jobs could create a refund in Stripe but encounter an error when it tries to update the payment status in the DB, and if the job is retried, it might attempt to issue another refund (though there are other ways I can safeguard against that, I think).

clear ridge
#

The automatic refunds are processed in background jobs with automatic retry logic as well

Why not just enqueue the "manually refund[ed] individual tickets" too in the same queue?

brazen wing
#

I might be able to make that work, but background jobs are run concurrently (we're using Graphile if that matters), so the same TOCTOU issues might happen if multiple jobs are enqueued to refund the same payment.

clear ridge
#

Not if they have the same idempotency_key.

#

Oh.

brazen wing
#

I'm having trouble squaring the need to ensure that successful refunds are only ever issued once, while allowing failed requests to be retried. Changing the idempotency key across retry attempts would break the first requirement but keeping it stable would break the second, if I'm understanding things correctly.

clear ridge
#

create-refund-${paymentId} would work if you're using automatic retries (I'm almost certain) and you could use that to dedupe the jobs.

#

You are understanding things correctly. I think your logic is sound, and you were correct - what you want to do will almost certainly do what you want.