#nicolas-z_webhooks

1 messages · Page 1 of 1 (latest)

sage briarBOT
#

👋 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/1361638850165735434

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

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

swift sleet
#

Hi

white pelican
#

Hi, let me help you with this.

#

those event cannot be success at all.
What do you mean by this?

swift sleet
#

Let me explain it. Previously, our backend service that handle the webhook do not response properly (it would return 0 for success), so there were a lot of events pending to retry

#

and today's morning, I fixed these return status problem and disabled almost all the webhook event callback on dashboard (only 5 of them were enable)

#

so I found that the events that were in pending status would still keep retrying and do not callback to my backend service (maybe because I disabled them)

#

So I wanna ask if there are some ways to make those in retrying status events success?

sage briarBOT
little imp
#

👋 taking over for my colleague. Let me catch up.

swift sleet
#

thank you

little imp
#

the only way to stop retries is to delete the webhook endpoint and add it again. We do not recommend this since it will stop delivery for any event pending and any event created while the webhook was deleted.

#

you can start by creating a new webhook first and then delete the old one

#

this way you can ensure that you won't have any missed events

#

but it might generate duplicates

#

so it's really a tradeoff

swift sleet
#

so after I disabled the webhook event callback, stripe system would keep retrying the events, but it would not do real delivery, right?

little imp
#

so after I disabled the webhook event callback, stripe system would keep retrying the events, but it would not do real delivery, right?
if you delete there will be no more retries for the past events

swift sleet
#

you mean delte the endpoint or the not successful status event?

little imp
#

the endpoint

#

sorry I thought I was more clear on that

#

you can't delete events

swift sleet
#

What happen for the not successful event then if I delete the endpoint

#

will it have some affect on my customer's subscription?

little imp
#

it will no longer be retried

little imp
swift sleet
#

if I do not delete them, will it retry it forever, do your system have the maximum retry times?

little imp
#

no at some point the retries would stop since the webhook endpoint would be disabled

#

but once you fix the issue and you re-enable the endpoint then we would resume the retries

swift sleet
#

No, I mean I want to keep the webhook endpoint enable, beacuse we have logs and do not want to lose them, so I wanna confirm if the retrying events will keep retrying forever?

#

what is the maximum retry times if the events callback keep failure?

little imp
#

No, I mean I want to keep the webhook endpoint enable, beacuse we have logs and do not want to lose them, so I wanna confirm if the retrying events will keep retrying forever?
I don't think that's the best option here

#

at some point the webhook endpoint will be disabled

swift sleet
#

yes, I disabled some events for the endpoint now, the endpoint only have 5 events currently

little imp
#

I would highly recommend returning a successful HTTP response to the events that were previously failing if you don't want them to get processed again