#sofian-webhook
1 messages · Page 1 of 1 (latest)
as events are unordered, i would like to add a +30s delay instead of returning an error, while waiting for the previous event
ah that's short
i really dont see any good practice to handle this unordering pb
you could recieve the event and then push it into some local queue or holding state as a layer between your endpoint and the application code; but holding open the HTTP connection with us for ~30s is not really an option at all
with have success before processing on charge, mainly
generally the way to do it is to handle things by retrieving the object in the event
yep and emulate stripe retries ourselves then ? But we will also need to implement a whole new system to resend / check errors as on dashboard everything will be 2XX
so if you get charge.pending, you actually just go and retrieve the Charge object from the API
or refetch the event i guess
that gives you the current up-to-date status of it and that's what you reconcile your system with
well re-fetching the event will just give you the same snapshot, so no
you'd retrieve the event.data.object.id basically
our system currently works well if success event is resend after we received the pending (even if it was first sent as success, resulting in an error)
ok major refactoring will be needed
we have avg response time of 7s and 21s max, how bad is it ? (i dont think that bad as we managed ~100k€ per day :/ )
that's not ideal! AFAIK right now we have a 30s timeout(up to 10s to connect and get the SSL handshake done), and after that you have the remaining time to send a response before we time out the connection; though it's changed in the past so I tried to avoid giving you the specific numbers
there's a cost on our side to having a bunch of HTTP connections open given the scale we send webhooks at so we have to be a bit aggressive in timeouts if your end is not responding. As such I'd really try not to build things where you reject the event because you want us to resend it later, that's really not how we intend for this to be used. Generally out-of-order events are better handled by retrieving the referenced object and then handling those in an idempotent way
is there any way for us to see if timeouts occurred in our webhook (i mean closed connections from your end) via the dashboard ?
i dont have any log error such as client force disconnected
you can look at failed attempts on the page for the endpoint itself, linked from https://dashboard.stripe.com/test/webhooks, but I don't think you can really filter the list much. Time outs show something like "HTTP status code : Timed out" on the attempt
thx, i'll dive in it. I dont remember having seen this kind of error yet