#AndySeigel
waxen fractal
sick sable
Can you just re-post/summarize here?
It looks like something to do with the webhooks developer dashboard, but you're talking about manually re-sending, which should not be necessary
We automatically retry if the delivery transiently fails
Is this not happening?
Or are you having complete failures and trying to manually re-send some of those events?
Can you share some specific event ids that arent working like you expect?
stone rock
so, I do not understand the error: stripe shows error. Then I click retry and it works. can I get detail on what the error is on the stripe side?
is it a timeout, is it you got an error response back from my service, etc
sure
this one failed: "id": "evt_3LoaqHGW0FrkoFak3TZM7McK",
then on retry it worked (no change on my end): "id": "evt_3LoaqHGW0FrkoFak3TZM7McK",
sick sable
Thanks, looking
So this looking like it failed initially, then you manually re-sent for a success, then the original delivery retries happened and the last one got a successful response from your server (about 3 hours after original)
stone rock
thats odd, because I clicked retry right after it failed, and it went through. What I don't see though in the dashboard: is what the error was just says "ERR":
sick sable
It appears that your server is intermittently timing out when we try to deliver
Right, because a time out means we couldnt reach your server
sick sable
Are you hosting this somewhere that "sleeps" and needs to wake up?
It possible the first try woke up the server, but too slow to handle the request, then your retry worked
No, it can fail different ways, but this one timed out
stone rock
no I don't think so. Its just a regular azure vm with a dedicated IP address, internal DNS on a azure dns zone, and external DNS at google
and the site is IIS
with really, really basic/simple stripe code for the webhook
sick sable
You can expand the delivery attempt in the dashboard to see:
HTTP status code
Unable to connect
The next step would be to review the network logs on your server to see if you received the request but failed to handle it, or if you never received it. If you aren't receiving it, you might need to work with your hosting provider to determine the cause.
stone rock
oh i see the timeout now, you have to do 'view event' first, and then the table has more choices
ok, I will see if I can. thank you
stone rock
Indeed, the successful ones show in the IIS logs (as 200), and the timeouts do not show at all.
sick sable
Right, so something is prevent our requests from reaching your server then, in some cases
stone rock
So, stripe documentation actually distinguishes 'unable to connect' from 'timeout', it looks like it was 'unable to connect'. Does that mean it could not even resolve my URL, as in I should be looking at DNS you think?
so weird that all other requests to my server work, including stripe, execept for the stripe websocket/webhook
and that those work 1/2 the time
violet osprey
Are you looking at the same event ID above, or a different event?
stone rock
im looking at one from today, that failed, then worked on an auto-retry (without me clicking it): https://dashboard.stripe.com/test/events/evt_3Lou3LGW0FrkoFak0eRyIi7O
your 'first request woke it up' theory from earlier, actually would make sense based on todays behavior -> except that I didn't see any request in the logs
I guess a ticket with azure might be next, as you said, I should have seen the request. Just feel like im missing something obvious, though.
violet osprey
Interesting. The logs on my end for the first attempt (the one that failed) show an "unable to connect" error
stone rock
how long does stripe allow before it cancels the websocket request?
violet osprey
In case it helps narrow down with Azure, the first (failed) attempt and second (successful) attempt to deliver evt_3Lou3LGW0FrkoFak0eRyIi7O happened in the same minute