Skip to content

24. Troubleshooting

[← Monthly Checklist]/23-monthly-checklist/ · [Index]/00-index/

24. Troubleshooting

Verified against: field/status inventories already built in Sections 3, 5, 8, and 15, plus cancelOrderWorkflow’s source (confirms reservation release on cancel — detail below).


Product not visible on the storefront

Check, in this order:

  1. Status — must be published, not draft/proposed/rejected. See [Section 3]/03-product-management/#status—publishing.
  2. Sales Channel assignment — a product can be published but not assigned to the storefront’s sales channel, which has the same practical effect as being hidden. See [Section 20]/20-product-deactivation/#mapping-the-briefs-concepts-to-what-is-real.
  3. Category — only relevant once categories are actually used; today neither product is categorized and both are still visible, so this isn’t a live cause yet — see [Section 12]/12-categories/.
  4. InventoryTO BE CONFIRMED: whether an out-of-stock variant (with Allow Backorders off) gets hidden entirely or just shown as unavailable was not verified as part of this wiki. Don’t assume either behavior without checking the live storefront.
  5. Required fields — a missing HSN code does not affect storefront visibility, only GST invoice generation ([Section 16]/16-invoicing/). Don’t conflate the two when troubleshooting — a product can be perfectly visible and still break invoicing later.
  6. Images — not required for visibility, but a product with no thumbnail can render badly depending on the storefront theme.
  7. Storefront sync — a known caching bug can show stale data on the listing page specifically (product detail pages are correct) — see [Section 14]/14-payments/#known-accepted-gaps-not-silently-missing—documented-on-purpose. If only the listing page looks wrong, this is the likely cause, not a real data problem.

Inventory incorrect

Check, in this order:

  1. Reservations — a lower-than-expected Available number is often correct, not wrong: stock held against a real pending order reduces Available without touching In Stock. See [Section 5]/05-inventory-management/#reservations.
  2. Manual adjustments — the most likely real cause of a wrong number, since [Section 5]/05-inventory-management/#stock-adjustment already established there’s no audit trail — a past adjustment with no recorded reason is effectively invisible now.
  3. Orders — a completed sale reduces stock as expected; nothing unusual here unless an order was double-counted or missed.
  4. Cancellationsverified, not assumed: Medusa’s own cancel-order workflow calls a deleteReservationsByLineItemsStep, confirming that canceling an order releases its held reservation back to Available. If a cancellation happened but Available didn’t recover, that’s a real anomaly worth investigating, not expected behavior.
  5. Returns — a return’s “how many are damaged” input directly determines whether received stock is added back or written off ([Section 15]/15-refunds-and-returns/#return-received) — a wrong number there silently overstates or understates real stock.
  6. Physical stock — if none of the above explain it, the number may simply be wrong because no real stock-count process exists yet — see [Section 6 — Stock Audit]/06-stock-audit/.

Order not progressing

Check, in this order:

  1. Paymentrequires_action or not_paid blocks meaningful progress; use Check Status to re-poll Razorpay. See [Section 8]/08-order-management/#payment-status-values and [Section 14]/14-payments/#troubleshooting-payment-successful-but-order-pending.
  2. InventoryTO BE CONFIRMED: whether checkout can complete at all against a zero-Available variant (with backorders off) was not verified — this store has never actually tested that edge case end-to-end.
  3. Order status — remember payment status and fulfillment status are independent tracks (see the correction in [Section 8]/08-order-management/#correcting-a-assumption-from-the-original-brief) — check both, not just one.
  4. Shipping — fulfillment requires a valid Location + Shipping Method combination ([Section 9, step 10]/09-order-processing-sop/#10-fulfill-items); if none is configured correctly for the order’s region, fulfillment will fail at that step.
  5. Errors — there is no admin-visible error/system log. Anything not explained by the above needs a developer looking at server logs directly — not something fixable from this dashboard.

Payment successful but order pending

Already covered in full in [Section 14]/14-payments/#troubleshooting-payment-successful-but-order-pending — not repeated here to avoid the two pages drifting apart. Short version: check Payment status, then use Check Status, then escalate to a developer if still unresolved.


[← Monthly Checklist]/23-monthly-checklist/ · [Index]/00-index/ · [Next: Audit & Change History →]/25-audit-and-change-history/