Nearle/kubernetes
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix: route queue.workolik.com createorder to jupiter's v3 (item-aware) handler

Browse Source 
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.
This commit is contained in:
Suriya
2026-07-29 17:52:44 +05:30
parent d98ebdd152
commit 661a08d0b7
1 changed files with 8 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
manifests/core/worker-script.yaml
View File

@@ -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",