#sofian-webhook

1 messages · Page 1 of 1 (latest)

sick apex
#

yes, it's around 10 seconds though it's subject to change

rocky obsidian
#

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

sick apex
#

yeah you can not do that, sorry.

rocky obsidian
#

i really dont see any good practice to handle this unordering pb

sick apex
#

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

rocky obsidian
#

with have success before processing on charge, mainly

sick apex
#

generally the way to do it is to handle things by retrieving the object in the event

rocky obsidian
#

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

sick apex
#

so if you get charge.pending, you actually just go and retrieve the Charge object from the API

rocky obsidian
#

or refetch the event i guess

sick apex
#

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

rocky obsidian
#

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 :/ )

sick apex
#

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

rocky obsidian
#

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

sick apex
#

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

rocky obsidian
#

thx, i'll dive in it. I dont remember having seen this kind of error yet