#jamie_webhooks
deep obsidianBOT
đ Welcome to your new thread!
â˛ď¸ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).
âąď¸ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can 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/1259866163022663751
đ Have more to share? Add details, code, screenshots, videos, etc. below.
steady herald
https://dashboard.stripe.com/events/evt_3PNaYoLjYDcRA6KW0h9E0YuI
I can not see the webhook attempts here, too far back
fading sealBOT
steady herald
Hi @craggy pewter, hoping you can perhaps see webhook attempts?
craggy pewter
Unfortunately you are correct that that is out of our retention
That being said, getting ocasional duplicate events is expected, so we reccommend making sure that your processing of these events is idempotent
steady herald
I have a feeling that the job handled too long, or was failed on our end - then stripe retries and our own job system retried also
it's a good 30 seconds later that the subscription, invoice was created etc
any suggestions how to reproduce duplicate events locally?
craggy pewter
If your theory is that your server initially returned a non-200 code which would cause us to retry the event, you could have your server purposely send another one.
Otherwise you can manually resend test events that are still within retention multiple times https://docs.stripe.com/cli/events/resend
Is that helpful? Or are you looking to reproduce something else?
steady herald
Okay thanks, nope that works I am reproducing it locally now by resending the event
perhaps you have a suggestion on what I should do in the webhook
check if a subscription already exists in Stripe?
craggy pewter
Can you tell me more about the situation that you are getting this event in? That is a tactic we often reccommend with webhooks: if your server hasn't heard of that object before it can retrieve it with the API
An idempotency reccommendation is to record the event ID of events as you process them and then when you get a new event you can simply no op and return a 200 if you have already processed that event correctly
steady herald
The setup is a bit strange as it is iDeal, and there are several work arounds when using iDeal and subscriptions (such as giving the user credit balance so the first invoice is automatically paid when we create a subscription after the first payment has come through)
so we create the subscription in the payment succeeded event if the payment method was iDeal
this means double subscriptions can be created in the case of duplicated events or jobs that are ran twice - the webhooks dispatches jobs on our end
craggy pewter
Ah gotcha, so yes checking to see if you already created a subscription is a great way to do that.