#h-mir_webhooks
1 messages ¡ Page 1 of 1 (latest)
đ 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/1448764765538095378
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
can see my manual retry succeeded, not sure why auto retry is still retrying. Should not need to handle it in my service end, ideally a capability to cancel the retrying would help
I can see the delivery of the manual response but you will need to respond with a 200 to the next automated retry to prevent future retries
What is preventing you for responding properly to the recurring events?
disabled it when it tried to send and now its stopped. As this was part of setup we had a failed webhook event for which I had manually conducted the required actions our end and for which a retry is not legal and breaking. I would have had to put logic into production to respond with 200 for a specific case, feels like the better thing is just to have control over retry?
any ideas if this is a feature on your roadmap?