Yesterday, my app broke after working fine for a number of months. I have tracked it down to a failed Graph QL call, and I’m able to replicate the issue on the Shopify GraphiQL App. It errors out anytime I include the “inventoryQuantities” property for a variant on a productVariantsBulkCreate mutation. I can include the entire response, but the message I get back is “message”: “The server responded with invalid JSON, this is probably a server-side error”.
If I remove the “inventoryQuantities” property from the variants in my payload, I get a proper response back. I know yesterday was a release day for the new API version, but I did not see any changes related to my issue, and changing versions of the API seems to be of no help. One interesting thing is that it seems to create the variants, but gives back a response indicating an error. If I view my variants afterwards, the new variants are there, with inventory values set properly. When the “inventoryQuantities” property is included, the call takes a few minutes to return, as if it is waiting for something to time out before responding with an error message.
Any information regarding this issue would be much appreciated. I have attached an example request that causes the error.
For some reason, it won’t let me upload the response as a text file. So, I’m just going to post it here.
{
“message”: “The server responded with invalid JSON, this is probably a server-side error”,
“response”: “\n<html lang="en">\n\n <meta charset="utf-8" />\n <meta name="referrer" content="never" />\n <meta name="viewport" content="width=device-width, initial-scale=1">\n Something went wrong\n <style type="text/css">\n *{box-sizing:border-box;margin:0;padding:0}html{font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;background:#F1F1F1;font-size:62.5%;color:#303030;min-height:100%}body{padding:0;margin:0;line-height:2.7rem}a{color:#303030;border-bottom:1px solid #303030;text-decoration:none;padding-bottom:1rem;transition:border-color 0.2s ease-in}a:hover{border-bottom-color:#A9A9A9}h1{font-size:1.8rem;font-weight:400;margin:0 0 1.4rem 0}p{font-size:1.5rem;margin:0}.page{padding:4rem 3.5rem;margin:0;display:flex;min-height:100vh;flex-direction:column}.text-container–main{flex:1;display:flex;align-items:start;margin-bottom:1.6rem}.action{border:1px solid #A9A9A9;padding:1.2rem 2.5rem;border-radius:6px;text-decoration:none;margin-top:1.6rem;display:inline-block;font-size:1.5rem;transition:border-color 0.2s [email removed] all and (min-width:500px){.text-container–main{align-items:center}.page{padding:7.5rem 10.5rem}}\n \n\n\n<body class="status-error status-code-500">\n<div class="page">\n <div class="text-container text-container–main">\n
\n <h1 data-i18n="content-title">Something went wrong\n <p data-i18n="try-refreshing">There was a problem loading this website\n <p data-i18n="try-again">Try refreshing the page.\n <a href="." class="action" data-i18n="refresh-page">Refresh Page\n
Thanks for sharing so much info here, I was able to look at the examples you shared, however in order for us to get a better idea of what is happening we would require a bit more info. If you are able replicate this behaviour, please share back an x-request-id response header value from a request where the error was returned.
I can attempt to locate logs, pass back insights or next steps moving forward, and will keep an eye out here for the time being - Cheers!
I was unable to locate any request logs related to the id value shared above. Could you try replicating the original request with your app or an API client such as Insomnia to provide another x-request-id to investigate - an example of the mutation body, input, and response body would also be greatly appreciated.
No rush, and happy to take a look once we have that info - Thanks!
Could it be because the x-request-id is for a development store? I can generate another x-request-id, but I have made a temporary workaround for my client & do not want to trigger the error on the live store.
Happy to hear the behavior you outlined is no longer present. Just wanted to connect again to offer a quick summary and some insights moving forward.
While our team can’t provide authenticated supported through these community forums, details such as an x-request-id provide a means of locating logs we can investigate. It’s understandable not wanting to attempt replicate something unexpected in a ‘live’ senario, but is worth noting that this header value will be returned regardless of being on a merchants store or development store. When a behavior can’t be replicated, we usually suggest keeping an eye out for persistence or additional occurrences.
I did have an eye out for any related reports, but wasn’t able to replicate or find any other instances of what was initially described. Lastly, while I can’t confirm potential changes that would be specifically related, our developer are always actively making platform improvements and fixes.
In the future, when facing a potential bug or unexpected API behavior, don’t hesitate to use the Shopify Partner support - Report an issue option that was recently added.