We’ve identified the root cause as an inventory syncing issue and shipped a fix. 422 errors should now be rare but not completely non-existent (data population still takes time).
Thanks all for reporting this issue!
If you’re still encountering issues, please share recent request IDs we can investigate, as @ahmedrizwan239 has done.
Yes Still facing issue Request ID: 01300b04-c35f-406e-bccf-8eef4d04f19e-1775009243
Thanks for your patience while I looked into this.
The 422 in these cases is expected behavior. There’s a propagation window
between an Admin API write and when the cart service recognizes the new
variant as eligible. Hitting /cart/add.js during that window returns a 422.
Immediate cart availability after variant creation isn’t guaranteed.
There’s no endpoint or webhook to signal when a variant is “cart-ready,” so
retry logic is the best approach if you’re still encountering issues.
We are having the same issue. Request ID: dbbadf6b-e705-4ff4-b539-9bb2d0f5d7f2-1776308501
{“status”:422,“message”:“The product ‘Traditional Lentil Stew’ is already sold out.”,“description”:“The product ‘Traditional Lentil Stew’ is already sold out.”}
The product is in stock, assigned to a shippable location.
Update:
We’ve investigated the additional request IDs reported here, and can confirm these cases experienced expected behavior. The increased complexity of products over time has led to an increase in propagation time.
If you’re still experiencing this issue after the optimizations we’ve recently made, retries with exponential backoff remain the best available approach going forward.
Also dealing with this issue.
I made an observation that may be useful if you’re dealing with this.
When you create the variant with stock tracking enabled (and also link it to a location and give it stock, I just give it 9999) - the propagation delay is gone, no more 422’s.
Could be a workaround depending on your situation. Disabling stock tracking seems to be triggering this delay.