When you audit a Shopify store for their delivery profiles, you get back a list of the setup zones, and within those zones, the carriers, and the various services they provide. The Bug can be explained as follows.
Orders were booked on March 5th that resulted in a shipping service being assigned to orders: First Class Package International
Yesterday I made a GraphQL inquiry on the shop that resulted in the carrier being correctly returned, USPS, but there were no participantServices. In other words, this Shopify store did not have any services ticked off in their Admin such as First Class Package International. This means customers would not be offered that option, and that option could not possibly be assigned to an order.
So when I logged into the Admin, and dug in, and found all the options unchecked, I did an experiment and turned on one of the options, and did a save.
Now my GraphQL query came back fully populated with all the participantServices populated, meaning if I saw an order with First Class Package International assigned to it, I would be able to look at the participantServices list and see that as an option.
The BUG is that I could not uncheck the service, leaving the list blank and empty as I first found it. Shopify has a rule in place that prohibits this. So how did this store initially present this condition to me in the first place yesterday, where there were no participantServices?
I am worried about the validity and robustness of the Shopify API in this case, as it seems that with some inputs from the merchant, orders can be booked but we cannot know the correct delivery profile assignments using the API. Since this grossly affects shipping with external third-party fulfillment operations, this seems like a serious problem to me.
Can I get a comment from Shopify please? Is this is a known issue, and if so, is it actively under study?
Can you kindly provide the order_id that experienced this issue? I've tested myself and saw similar behaviour, in my case the test shop didn't have any active carriers, but I wasn't able to activate one without checking at least 1 service. I'll dig in on that order and attempt to replicate.
I do not remember the exact order. I did not record it. It still exists, but I cannot be precise, so I will skip it. I have since learned of the importance of using the active status flag on the participating services, but honestly, this exact bug still does kinda haunt me.
It was certain that when I examined the participating services, NONE were ticked off for that carrier, especially not that one that was booked with the orders. And thus being unable to save that empty roster, this whole conundrum rears its ugly head. If you are forced to tick off at least one participating service, how it that I was presented with an empty slate in the first place, even though orders had used one.
I write this off as a problem in React and the front-end Admin codes. More than likely was just a glitch in the UX code that has probably since been fixed.