lightward
'Phantom reservations'
I work for a company that relies heavily on Draft Orders. Sending customers a "quote" in the form of a "draft order" probably accounts for 20% of our business, if not more. Dozens, sometimes hundreds of draft orders are processed daily.
The problem is this: there appears to be a mysterious set of conditions that prevents the reservation from releasing after a draft order is flipped to "completed". This bug is rare, it's been observed to happen on far less than 1% of all "completed" drafts since we initiated this Mechanic Task. All said, it's still enough to cause headaches.
Please trust that I have contacted Shopify support and they were of no help. And I can appreciate that this issue may be beyond the scope of this mechanic task. Without getting into it I believe Shopify does some weird things at the application level in admin, making is seem as if there's seamless integration when there is not. I'm not a skilled coder and far from an expert on these thing, so I'll leave it vague, I may be naive...
With that, a few questions:
In your documentation you say this:
The one minute delay on the draft order update subscription and the enabled "Perform action runs in sequence" run time option should both be left as configured, to prevent interference with draft order completions and updates
-This seems sensible, but could you describe this interference? I'm assuming you did testing? -could the task be modified in such a way that it will hook reservation before the draft is saved, or usurp the tagging bit entirely? (I did write out a modified script, but I'm a little apprehensive about testing it out, for reasons I would essentially have to make it live to do so) -In troubleshooting I played around with modifying the "reserveInventoryUntil" date on reserved draft orders via javascipt (via apps script) to reduce the reservation period. This only worked for NON-completed drafts. Completed drafts appear to be untouchable till the reservation expires. Any insight would be appreciated.
@human785 For a little background, see #310 on how this task came about (a Shopify bug/feature 🐛 ).
The problem is this: there appears to be a mysterious set of conditions that prevents the reservation from releasing after a draft order is flipped to "completed".
I believe what you are encountering is beyond the scope of this library task. With enough digging, there might be a repeatable pattern due to some oddity in the draft order data, but given that the task only passes an ID and date into a single API call (draftOrderUpdate) there really isn't much to consider changing.
The "Perform action runs in sequence" is enabled on that task to allow the task to make the Mechanic cache call before the draft order update call. When the task sees the draft order again (because it just caused an update webhook), having an accurate cache value is essential to preventing a resource loop.
Reaching beyond this task, there might be a way to remediate the effect of the behavior you are encountering. A custom task could be developed to scan recently completed draft orders, querying the "reserved" inventory quantity for each line item, and (ideally) identify any that are "phantom". It would then use either the inventoryAdjustQuantities or inventoryMoveQuantities to remove (or move) the phantom reservation quantity.
If you'd like, you can reach me - Brad (Tekhuas) - in the Mechanic slack to discuss this possibility further.
In researching this anomalous issue, it was noted that the original Shopify bug appears to have been resolved. #457 was added to simplify the task, which may help prevent the confluence of draft order updates, reserving, tagging, and completing that is suspected to be a cause of the phantom reservations.