@sb2020 I’ve seen this happen consistently with some of our older orders, but I never reached out to the dev team to determine the cause. My “fix” was to start my data pull from a more recent date (not an actual fix, I just decided that we could get by without that historical data).
For what it’s worth, I haven’t had this issue on any orders later than October of 2019.
For me it fails for any orders query, not able even to load yesterday sales:
query {orders (updated_from: “2020-09-01 11:53:09”) { data (first:100 ) {pageInfo {hasNextPage endCursor} edges {node { id }}}}}
Hi @sb2020
I apologize for the delay in my response.
I see the error you are mentioning and have already submitted a ticket to engineering to see why it might be happening. There seems to be an error with the Authorization part of the orders, but that should be resolved on our side.
I will let you know as soon as I have an update from them.
Thanks for the patience while we fix this.
Tom
Hi @sb2020
I apologize for the delayed response, I just engaged our engineers to see if we could get a fix asap about this.
Is it happening to multiple accounts or just this one?
Thanks again!
Tom
Thanks for clarifying that @sb2020
An engineer has been assigned to work on this, so we should have news soon.
I will let you know asap.
Thanks again!
Tom
We have an orders query that has been consistently failing with Code 22 for a couple days now. More info for your team to help get this solved hopefully.
We reached out to support but were told the community is the best place for API support.
Please let us know if this is still in progress and/or if your team has any news.
Thank you!
-Sid
@tomasw More info, I got our script to go ahead and include our query parameters in the output so I could see which order is giving us trouble.
Order ID is T3JkZXI6MTQ3ODk0NTM2
@tomasw With that diagnosed, we were able to add a temp fix to our script to get around this problematic order, and then everything else went through properly.
We can’t simply skip data whenever we get a code 22 response since they happen randomly/sporadically. Maybe we could add some logic in to go ahead and skip the data if we consistently get a code 22 for the same request after X times. I’d really rather avoid that, and since the request is valid the ideal behavior of course would be that it eventually gets a valid response.
FYI, this is pertinent to our python scripts only, but here’s the jist of how we put a fix in place once we knew the problematic order id:
if query_params == "id: \"T3JkZXI6MTQ3ODk0NTM2\"":
# Temp fix for sh**ty order
has_next_page = False
A fix for this should have been implemented on 16/10/2020 I apologize for the delayed update about it.
@originsid
I believe that might not be related to this fix, and that order has an invalid value for one of the line items price, causing it to break the response, this is:
Order ID: T3JkZXI6MTQ3ODk0NTM2 is seen this way in the UI:
For that specific line item, it was manually added to the order, and it looks like the intent was to zero out the pricing on it. Most likely we deleted the price and saved it, rather than setting it to 0.00
Does that make sense as a cause of this? Should we make sure it’s standard procedure to never set a blank value for price on a line item?
Since we’d rather not do any strange re-shipping for this one to correct it, would you mind setting that value to 0.00 on the backend as you described?
Hi @originsid
The issue should be resolved by now! I set it to be 0.00
It does make sense, for example, if when creating an order you try to set a letter for the value “ABC” you will get an error because it is not a number. So I think it is possible that might have happened.
Let me know if you continue to face this kind of issue or if there is anything else I could help with.
Thanks again!
Tom
Thank you @tomasw!
FYI in the order history for this one, I can see the log shows “removed price”.
If removing the price on a line item is normal behavior, I think it would be preferable for the API to handle line items with the price removed, but if it’s not normal behavior I definitely understand that and I think it would be preferable to force the price to be 0.00
If it makes more sense to allow the price to be removed but not handle those line items well via the API then there may be a use case I’m missing, happy to learn more about it.
Currently we wouldn’t have a way to detect line items with no price since we can’t pull that data via the API.
Hi @originsid!
Makes sense to report that change.
I think forcing it to 0.00 might be the best call, empty prices might cause some issues and not only here on the Public API (generating invoices for example)
I will try to reproduce on my test account and submit a ticket for that to be changed.
Thanks again for catching this! And let me know if there is anything else I could help with
Tom