From 661a08d0b708e4d22645bc319bc984a020db4929 Mon Sep 17 00:00:00 2001 From: Suriya Date: Wed, 29 Jul 2026 17:52:44 +0530 Subject: [PATCH] fix: route queue.workolik.com createorder to jupiter's v3 (item-aware) handler worker-script's ENDPOINT_MAPPING sent /live/api/v1/mob/orders/createorder to jupiter's v1 CreateOrder, which only ever writes the order header - it never loops over "items", so orderdetails/productstocks were silently never touched for any order placed through queue.workolik.com. itemcount (a plain scalar on the same Orders struct) persisted, making this easy to miss: header looked fine, items silently vanished. Confirmed live before the fix: order 147157/147159 (tenant 1147) had itemcount=1, detail_count=0, stock unchanged. Root-caused via jupiter's own log line (orderController.go:393, the log statement inside CreateOrder) at the exact timestamp of the test request. Repointed to /live/api/v3/orders/createorder (CreateOrderv3), which does loop over Items and write orderdetails + productstocks. The loop is a no-op when Items is empty, so tenants whose entire order history is header-only (916, 908 - confirmed ~99.5%+ itemless across 100k+ and 6k orders respectively) are unaffected. Verified live post-fix: order 147160 got itemcount=1, detail_count=1, and product 7076's stock ledger moved 25->24 on create, restored to 25 on cancel. Tenant 916 traffic unaffected by design (empty-Items loop is a no-op), not yet re-observed live since the restart pending their next natural order batch. Test orders (147157, 147158, 147159, 147160) cancelled, not deleted. --- manifests/core/worker-script.yaml | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/manifests/core/worker-script.yaml b/manifests/core/worker-script.yaml index 6894684..4f1cc73 100644 --- a/manifests/core/worker-script.yaml +++ b/manifests/core/worker-script.yaml @@ -56,7 +56,14 @@ data: "/live/api/v2/deliveries/createdeliverylog": f"{BASE_URL}/live/api/v2/deliveries/createdeliverylog", "/live/api/v2/partners/createbreaklog": f"{BASE_URL}/live/api/v2/partners/createbreaklog", "/live/api/v2/partners/updatebreaklog": f"{BASE_URL}/live/api/v2/partners/updatebreaklog", - "/live/api/v1/mob/orders/createorder": f"{BASE_URL}/live/api/v1/orders/createorder", + # v1 CreateOrder only ever writes the order header - it never loops + # over "items", so orderdetails/productstocks are never touched. + # CreateOrderv3 does ("for _, item := range data.Items"), and the + # loop is a no-op when Items is empty, so tenants who never send + # items (their whole order history is header-only, e.g. 916/908) + # behave identically. Tenants who do send items now get them + # persisted instead of silently dropped (2026-07-29). + "/live/api/v1/mob/orders/createorder": f"{BASE_URL}/live/api/v3/orders/createorder", "/live/api/v1/web/products/create": f"{BASE_URL}/live/api/v1/products/create", "/live/api/v1/mob/customers/login": f"{BASE_URL}/live/api/v1/customers/login", "/live/api/v1/mob/customers/create": f"{BASE_URL}/live/api/v1/customers/create",