We use a fraud screening service that due to sometimes requiring manual review we initially put orders in a hold status, then update to accepted once we get the approval from that service. In most cases that means our ordoro integration is creating the order then trying to update it due to status change less than a second later.
The problem is the API often returns a 404 retrieving that order so soon. However it DOES accept updates to that order. My assumption is you are using writer and reader endpoints to your database so the first request returns a 404 as the reader has not yet synched that data, but the writer does see it and updates the order. Since my update function is comparing order contents to see if the products content was updated and it sees no contents in the ordoro order it ends up creating duplicate products.
My only options to mitigate this was to either cease the entire synchronization process (not good) or skip the product contents update part if there is no response and update the order update timestamp on my end to trigger a cron update later.
However this seems easily addressable in your API. If I am POSTing to /v3/order/{order_number}/line and include a ‘cart_orderitem_id’, that presumably should be a unique id? Rather then blindly INSERTing a duplicate ‘cart_orderitem_id’ entry, shouldn’t you make it UPDATE if duplicate key exists? Thus failing gracefully by reverting to an update, without any extra db queries to check for duplicates (which would fail anyhow in this case if you’re using the reader endpoint to do so).
Just to make sure we’re understanding correctly, you are able to create an order (POST /v3/order), then update (PUT) it before you are able to GET the order?
Basically, yes. The order exists, but presumably GET is hitting a db reader endpoint that is not yet in synch so it returns a 404. PUT works, because it does exist on the db writer endpoint.
Thanks for the update. Can you tell me which PUT endpoint it is you are hitting that works even though the GET /v3/order/<order_number> endpoint returns a 404?
All of them. Order status, tags, shipping address, product lines, all update. To be clear, the put is not the problem. The order exists. But the get request returns 404 anyhow. Again it’s seemingly because it’s requesting it too soon after to the order was created. I even tried working around it with a do while loop that sleeps for 1 second then tries again up to 3 times (to prevent a runaway loop for unknown reason that order really doesn’t exist) if it gets a 404. So I can say that the delay can be significant not milliseconds.
Orders in Ordoro are not accessible or modifiable until after the rules engine has finished processing, which could take several seconds. This is to prevent race conditions between rules and user/API interaction.
The order does exist in the database, so a second POST will result in an error response. However, PUTs and GETs will also fail during this time as if the order does not exist until the rules engine has done its job. This is the weirdness you’re seeing. I imagine by the time you’re PUTing, the order has finished processing and is ready for interaction.
Interesting. That might explain why when I tried the workaround that would keep retry three times with a 1 second sleep in between it actually increased the number of orders getting duplicate product lines.
Any suggestion for a workaround? I could just remove the 3 retries cap and have it keep retrying every second until it does not get a 404. Aside from slowing things down, I’m just afraid of some oddball case where we have a order_number mapped (which should only happen upon successful creation of the order) but some reason the order just does not actually exist and it triggers a runaway loop.
Can I differentiate from the error whether the order actually doesn’t exist or its just not ready yet? Like a 404 means “keep retrying”, a 5xx means “it doesn’t exist: stop!”?