I know this question has been asked before and reviewed those answers but still not finding solution to my issue. Basically I have a simple webhook for fulfillment creation, and it is being called twice exacly each time I update an order.
I understand that it is important to return a 200 OK status immediately to shopify so it will NOT try to send messages multiple times. Now the "frame" of the "immediate" is defined as within 5 seconds as explained in shopify tutorial here https://help.shopify.com/api/tutorials/webhooks
Now I am responding far earlier than that according to the logs, the only missing part would be i wouldn't know how long it takes when actually shopify server processes my response. But please see the below output from the server that receives the web hook.
As you can see the first request already responsed with status 200 within 402ms and the second one within 506ms. So why would I receive these notifications double every single time? Is there any other thing that might be affecting the behaviour?
Jan 14 21:38:15 myproject heroku/router: at=info method=POST path="/order.php" host=myproject request_id=00000000-0000-0000-0000-00000000 fwd="0.0.0.0" dyno=web.1 connect=0ms service=402ms status=200 bytes=324 Jan 14 21:38:15 myproject app/web.1: 188.8.131.52 - - [15/Jan/2017:05:38:15 +0000] "POST /order.php HTTP/1.1" 200 - "-" "Ruby Jan 14 21:38:15 myproject heroku/router: at=info method=POST path="/order.php" host=myproject request_id=00000000-0000-0000-0000-00000000 fwd="0.0.0.0" dyno=web.1 connect=0ms service=506ms status=200 bytes=324 Jan 14 21:38:15 myproject app/web.1: 184.108.40.206 - - [15/Jan/2017:05:38:15 +0000] "POST /order.php HTTP/1.1" 200 - "-" "Ruby
This exact thing is happening on my webhook as well. It started Feb 1st after years of running properly. I'm sending header('HTTP/1.1 200 OK'); at the top of my file so the response is well within 5 seconds. As far as I can tell this is Shopify's issue and from searching the web it has been happening to shops as early as 2008. Luckily I caught this problem preventing over $10,000 in loss. I contacted Shopify support and they were 0 help, only saying the letters "API" make them turn into "a deer in headlights." Pretty dissappointed - and this is not the first of several major problems I've encountered with this platform.
I'd appreciate some insight from Shopify on how you can let this webhook problem persist for over 9 years and offer no solution nor do you fix it.
@Charles. It is up to you to catch the dupes. As you may guess, with hundreds of millions of webhooks being fired off, it is possible that you might get dupes happening.
The age-old wisdom is to simply record the webhook using a queue, and process it using code that reads from the queue, allowing you to check for dupes. There are even recent blog posts giving away free code that does that process so well, the App can handle millions of incoming webhooks, not lose any, and it costs mere pennies.
So instead of wishing Shopify would fix this for you, I think you might benefit from making a small but important adjustment to your code, writing to a queue, and moving on ... waiting for this to change is ineffective.
I have already done that Bill. Thanks though. If their actions dont meet the spec they provide then they need to change the spec. It is simply irresposible. Ntrfy showed above that they are well within their specifications of response time. All you are doing is making excuses for Shopify and placing blame where it doesn't belong. Of course I'm handling this on my side, I'm not an idiot.
Good for you! So if you are handling it like a champ, why are you complaining? I am not making excuses for anybody dude, I suffer along with everyone with platform problems. Anyway, moving on... have a nice day...
As someone who has developed similiar systems in the financial services world for three decades I would never, ever rely on a 3rd party providers assurances to the cleanness of their data or any assurances that it would arrive in a certain order or without duplicates.
Even if the interface meets the specs fully at the time of implementation there's no guarantee that a bit of rogue code or simple finger trouble could cause duplicates or other issues down the line.
It's not them that suffers the consequences so any code I write always caters for what could happen whenever possible rather than what the provider says would happen.
Thanks for the reploy, for some reason i missed it and read all the thread now. How can I send you the API key securely? This issue is still persistent.
As for the other discussion whether to handle it as a "champion" or not, without reading thread i had ended up logging the hooks and processing from there by dropping duplicates as well as our Shopify Export suggested here.
First of all, coding is time and time is money. If there is a spec and it doesn't work the way it is supposed to be, you spend time debugging it, contacting the support and finally fixing it yourself. Now do I have to do this myself or my employees everytime and just not bring it to the attention of the developer to fix it ?
Secondly, you can't always cover up for bugs like this, in this case you can figure out the dup by order id, carrier name and tracking number, what if this is financial app, it's passing me transactions? What if it passes me 2 exact withdrawal requests from account A to B within 500ms? Tell me how you are gonna say if it's dup or not? Simply because no human can enter two transactions in 500ms? what if it was 1s due to network lag and still dup? how would you differentiate? So the fact that, oh don't complain about the spec and just fix it, doesn't work folks, we depend on specs to do a certain job and report a certain output or error.
|an hour ago|
|an hour ago|
|an hour ago|
|an hour ago|