#ares_webhooks
noble lanceBOT
👋 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/1483057086563876946
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
jaunty mango
👋 happy to help
patent adder
hi
jaunty mango
you mean you received the event twice?
patent adder
We seen some cases when we get a webhook event twice. It fails on first try for unknown reasons and ends up succeeding the second try. here is one of the event IDs: evt_2T9vClqWxM0n7YqD1o6nvqzW
jaunty mango
yes we did attempt to send the event twice, because the first time your webhook handler returned a 500 HTTP response (Internal Server Error)
you need to check in your logs why it failed the first time
this is on your side not on ours
patent adder
When we trace back to the exact instance in the logs we don't see anything related to "internal server error".
So there is this related error message for the same event: SequelizeUniqueConstraintError: Validation error but if that is the case, how would it succeed the second time. I mean if there was a contraint error, it will always be as such for the same event.
jaunty mango
where is that SequelizeUniqueConstraintError error coming form?
patent adder
from the event handler, which basically recieves the event from stripe. So this error means the event object has some data attribute which violates the DB constraints but then it doesn't happen upon the event retry.
jaunty mango
maybe it's a auto-increment issue on your end when you're trying to add two entities in parallel
patent adder
both events have same time stamp and it is hard to see which one was sent first. If in the first try it was a success and in the second try it failed then it makes sense. Is that something you can check? I mean whether the first try was a success or failure.
jaunty mango
in all cases, you shouldn't use auto-increment, why not just rely on the IDs from Stripe?
patent adder
it is for other analytical stuff. I mean our internal records are kinda linked through these IDs. Also we have other payment processors that also share the table so cannot rely on stripe IDs.
jaunty mango
I meant instead of having auto-increment, use IDs whether it's Stripe IDs or other processor IDs it doesn't matter
if you have other providers that could explain why the first one is failing and the second succeeding
in all cases, there are 2 recommendations here:
1- use IDs instead of auto-increment
2- use a queue to streamline the operations on your side