#happycappie
1 messages · Page 1 of 1 (latest)
There are a lot of ways to handle this and unfortunately we don't have an official recommendation if it is coming down to a race condition on your end. Concurrency best practices are very system dependent
That being said, I don't know if that delay would be particularly helpful, if you have two threads now that are conflicting, adding that delay might just mean they conflict N seconds later
we are working w/rails and sidekiq, though the webhooks are being handled by a lamdbda function that creates background jobs in sidekiq
we were thinking of delaying the webhook processing 10, 15, or 30 seconds so that we at least give the checkout callback an almost guaranteed chance of winning
but wanted to keep the time delay as low as possible
do you have any stats on average Checkout callback response time?
95/5 or 99/1
Unfortunately don't have stats on that as that depends a bit on your network setup, that being said, we definitely recommend making your integration resilient to receive the client callback and webhook in either order. That would be a more robust way to handle this, while it probably wouldn't happen often the client callback could definitely happen after even 30 seconds sometimes