order.recheck iste'moli — 07 dan qaytish (R4, R12)

finalize-ep-10 yangiladi

Yangilandi: commit_sha, pr_url

qa-ep-10-t04-s05 statusni o'zgartirdi Review → Bajarildi

qa-ep-10-t04-s05 izoh qoldirdi

QA 2-raund (qa-EP-10-T04-S05, commit f51da9d) — AC3702 TUZATILDI, 4/4 mezon o'tdi -> done. == AC3702 — mustaqil probe (R1 defekt reproduktsiyasining AYNAN o'zi) == OrderA (received_at -10s, qty=10, band 4) · OrderB (yosh, qty=6, band 0) · sikl B uchun ochilgan, 6 dona tushdi (on_hand 4->10) · FAQAT recheck(B): OrderA: status=ready_to_deliver, qty_reserved=10.0000, ready_at yozilgan OrderB: status=in_progress, qty_reserved=0.0000 (R10 salbiy yarmi kuchda) stock qty_reserved=10.0000 — chiqim band qilinmay QOLMADI (R1 da 6 dona osilib qolgan edi) production_outbox: B uchun ANIQ BITTA yangi sikl (qty=6.0000) — R13ning o'zi, A uchun 0 qator R1 topilmasi yopilgan. == Yechim spec'ga tayanadimi — HA, taxmin emas == - 'Kutayotgan' status ro'yxati ('received','in_progress','ready_to_deliver','picking','picked') — 06_orders.md §4.3d invariant 2 (473-479-qatorlar) bilan SO'ZMA-SO'Z bir xil va S02 dagi sumOlderUnmetDemand ro'yxati bilan AYNAN mos (OrderLineRepository.java:75). - Butun navbatni yurish — §4.3b ('shu variantni kutayotgan buyurtmalar received_at o'sish tartibida yuriladi') va R13 ('06 HAR KUTAYOTGAN BUYURTMA uchun qoldiq yetishmovchiligini qaytadan hisoblaydi', 546-550). - Yangi biznes qoidasi to'qilmagan. src/main/java/uz/erpbom/tasks/ (EP-07) TEGILMAGAN (git show f51da9d -- src/main/java/uz/erpbom/tasks/ = bo'sh). openapi/ va db/migration/ diff (b441b81..HEAD) BO'SH. == Teskari xato (haddan tashqari keng yurish) — YO'Q == Probe: shu omborda BOSHQA variantni kutayotgan OrderC -> qty_reserved 0.0000 (tegilmadi); BOSHQA omborda SHU variantni kutayotgan OrderD -> 0.0000 (tegilmadi). Qamrov (warehouse_id, product_variant_id) juftligi bilan cheklangan. Yangi qulf tartibi kiritilmagan (processReceived har buyurtma uchun ketma-ket, alohida tranzaksiyalarda). S01-S04 himoyalari yashil: qaRepro_youngerOrderCannotJumpQueueWhenOlderOrderStillWaitsOnSameVariant, outboxProcessingOrderScrambledByRetryBackoff_barrierStillFollowsBusinessReceivedAtNotProcessingOrder, orderReceivedEvent_whenAutoAssemblyHitsSustainedLockContention_propagatesStockBusyAndOutboxRetries. == Mutatsiya (izolyatsiyalangan worktree, /tmp/qa-EP-10-T04-S05-r2, --force bilan o'chirildi) == M6 — processRecheck navbat sikli o'rniga eski xatti-harakat (faqat processReceived(orderId)) -> O'LDI: 2 test (coder AC3702 testi:1424 + mening probe'im). Ya'ni traversal HAQIQATAN AC3702 ni ta'minlaydi. M7 — findWaitingOrderIdsForVariant status ro'yxatidan 'in_progress' olib tashlandi -> O'LDI: 2 test. Status filtri yuk ko'taruvchi. M5 — ORDER BY received_at/id ASC -> DESC (teskari) -> TIRIK QOLDI (31 test, 0 failure; javap konstanta pulida 'received_at DESC' TASDIQLANGAN, OrderLineRepository.java:116). Sabab: sumOlderUnmetDemand to'sig'i taqsimotni yurish tartibidan MUSTAQIL qiladi — yosh buyurtma birinchi kelsa ham 0 oladi, natija bir xil. Bu defekt EMAS (natija spec'ga mos), lekin ORDER BY bandi testsiz: kelajakda tasodifan o'zgarsa hech qanday test sezmaydi. == 🔵 KUZATUV 1 (PM/spec uchun — bloklamaydi) — hodisa BEKOR QILINGAN buyurtma uchun kelsa == OrderReceiveReservationService.processRecheck (status tekshiruvi, erta return) — payload buyurtmasi received/in_progress da bo'lmasa (mas. cancelled, yoki allaqachon ready_to_deliver) navbat UMUMAN yuritilmaydi. O'lchangan probe: OrderB cancelled, uning sikli chiqimi 6 dona omborda; recheck(B) -> OrderA (eski, 10 kerak) qty_reserved=0.0000, stock qty_reserved=0.0000 — 6 dona yana band qilinmay qoladi (A o'z hodisasi kelguncha kutadi). Coder erta return'ni R11/R20 bilan asoslagan (bekor qilingan buyurtma qatorlari 'qondirilmagan' bo'lib ko'rinadi va navbatga TALABGOR sifatida kirmasligi kerak) — bu qism TO'G'RI: findWaitingOrderIdsForVariant status filtri cancelled'ni allaqachon chiqarib tashlaydi, shuning uchun variantni FAQAT 'ishora' sifatida olish xavfsiz bo'lardi. Spec (§4.3b/R12 va R20) bu holatni ATAYLAB qamramaydi — shuning uchun bu bargni bloklamadim; PM qaror qilsin (kerak bo'lsa alohida barg / spec savoli). == 🔵 KUZATUV 2 — R14 (Tovar2) navbat tartibi testsiz == Recheck traversali testlari faqat semi_finished (Tovar1) fixture'larida. finished omborda yurish tartibi ahamiyatli bo'lishi mumkin: yosh buyurtma birinchi ishlansa assembleAndReserveShortage semi_finished komponentlarni yig'ib set_assemblies.order_id ga O'ZINI yozadi (keyin to'siq uni 0 bilan cheklaydi — tovar yo'qolmaydi, lekin izlar yosh buyurtma nomida qoladi). M5 tirikligi shu bo'shliqning ikkinchi uchi. == Regressiya (surefire XML) == OrderOutboxWorkerTest 28 (kamaymagan — AC3702 testi o'rniga yozilgan, yangi qo'shilmagan) · ProductionOutboxWorkerTest 7 · WorkReviewProductionInIntegrationTest 4 · ProductionOrderIntakePortTest 7 · StockReservationServiceTest 6 · SetAssemblyCreate/Reverse/ListAndGet/Preview 9+10+10+10=39. JAMI 91 test, 0 failure, 0 error. AC3701/3703/3704 hamon yashil. Asosiy daraxt toza: git status bo'sh, grep MUTANT/QAPROBE src/ = 0, .orig fayl yo'q.

qa-ep-10-t04-s05 qabul mezonini belgiladi

✓ Buyurtma uchun ochilgan sikl chiqimi ham `received_at` navbatidan o'tadi — eski buyurtma oladi (R12)

coder-ep-10-t04-s05 statusni o'zgartirdi Ishlanyapti → Review

coder-ep-10-t04-s05 yangiladi

Yangilandi: commit_sha

coder-ep-10-t04-s05 qabul mezonini belgiladi

✓ Buyurtma uchun ochilgan sikl chiqimi ham `received_at` navbatidan o'tadi — eski buyurtma oladi (R12)

coder-ep-10-t04-s05 fayllarni qayd etdi

5 ta fayl qayd etildi

coder-ep-10-t04-s05 statusni o'zgartirdi Tayyor → Ishlanyapti

Agent ishni boshladi

coder-ep-10-t04-s05 ishga oldi

system statusni o'zgartirdi Ishlanyapti → Tayyor

Avtomatik bo'shatildi: 60 daqiqa signal yo'q

system bo'shatdi

Avtomatik bo'shatildi: 60 daqiqa signal yo'q

qa-ep-10-t04-s05 statusni o'zgartirdi Review → Ishlanyapti

qa-ep-10-t04-s05 izoh qoldirdi

QA (qa-EP-10-T04-S05, commit 635d25f) — 3/4 mezon o'tdi, AC3702 (R12) YIQILDI → qaytarildi. == AC3702 / R12 — DEFEKT (mustaqil probe bilan isbotlangan) == Fayl: src/main/java/uz/erpbom/orders/service/OrderRecheckPortImpl.java:23 (recheck -> processReceived(payload.order_id), FAQAT o'sha buyurtma). Probe (izolyatsiyalangan worktree, real Postgres): OrderA received_at=-10s, qty=10, qty_reserved=4; OrderB received_at=now, qty=6, qty_reserved=0; sikl B uchun ochilgan, chiqim 6 omborga tushdi (on_hand 4->10). FAQAT recheck(B) ishlangandan keyin O'LCHANGAN natija: stock: on_hand=10.0000, qty_reserved=4.0000 -> 6 dona HECH KIMGA band qilinmagan OrderA: status=in_progress, qty_reserved=4.0000 (TEGILMAGAN — aynan 6 kerak edi, olmadi) OrderB: status=in_progress, qty_reserved=0.0000 (R10 to'sig'i to'g'ri ishlaydi) production_outbox: OrderB uchun YANGI sikl so'rovi qty=6.0000; OrderA uchun 0 qator Ya'ni tizim omborda BO'SH turgan 6 donani hech kimga bermay, o'sha 6 donani QAYTA ishlab chiqarishga buyurtma beradi. Spec: §4.3b — 'Qayta tekshir eventi kelganda ham shu variantni kutayotgan BUYURTMALAR received_at o'sish tartibida YURILADI'; R12 (06_orders.md:536-545) — 'received_at bo'yicha eng eski kutayotgan buyurtma OLADI'; R13 (546-550) — 'chiqim boshqa buyurtmaga KETSA' (hozir hech kimga ketmayapti, lekin R13 netting baribir ishlayapti). Kod R10 ning FAQAT salbiy yarmini (yosh buyurtma navbatdan o'tolmaydi) bajaradi; R12 ning ijobiy yarmi (eski buyurtma OLADI) bajarilmagan. Kerakli tuzatish (yo'nalish): recheck payload'idagi buyurtma qatorlarining variantlari bo'yicha shu ombor+variantni kutayotgan BARCHA buyurtmalarni received_at ASC (teng bo'lsa id ASC — OrderLineRepository.sumOlderUnmetDemand bilan bir xil tartib) yurib chiqish, har biriga navbat bo'yicha rezerv qo'yish. Faqat payload buyurtmasini qayta ishlash yetarli emas. QO'SHIMCHA (agar traversal qabul qilinsa, birga o'ylansin): hozir eski buyurtma faqat O'ZINING production_runs (origin='order', WorkReviewService.java:640-653 faqat productionRun.getOrderId() ga recheck yozadi) sikli tugaganda oldinga siljiydi — 'production_runs.order_id egalik EMAS' qoidasiga (R12) zid bog'liqlik. Eslatma PM uchun (docs O'ZGARTIRILMADI): §8.3 (884-889) 'shu buyurtma qatorlarini received_at navbati bo'yicha' iborasi §4.3b/R12 bilan taranglik yaratadi — kelgusi aniqlashtirish uchun. == O'TGAN MEZONLAR (mutatsiya bilan tasdiqlangan, izolyatsiyalangan worktree) == AC3701 ✓ — M1 (ProductionOutboxWorker.java:146 order.recheck filiali o'chirildi; javap: filial bytecode'dan yo'qolgan, faqat create_from_order + notificationPort qoldi) -> 2 test yiqildi. Test mock'ni EMAS, haqiqiy worker.runOnce() -> claim -> process() yo'lini (real Postgres, production_outbox qatori) sinaydi; NotificationPort bo'shligi tasdiqlanadi. task.available (ProductionOutboxWorkerTest:200-209) va chain.reopened (SKIP LOCKED testi) hamon NotificationPort'ga boradi — buzilmagan. AC3703 ✓ — M4 (openRequestedQty chaqiruvi olib tashlandi; javap: openRequestedQty 0 marta) -> 5 test yiqildi, jumladan yangi recheck dedup testi (OrderOutboxWorkerTest:1458). Qo'shimcha QA probe: ochiq so'rov 10, kamomad 15 (dedup kaliti BOSHQA qty) -> recheck faqat 5 so'radi, dublikat yo'q. AC3704 ✓ — M3b (ready_at yozilmaydi) -> AC3704 testi yiqildi (ready_at ustun identity qoplangan); M3c (allMatch->anyMatch; javap: anyMatch) -> '3 dan 2 tasi to'la' testi yiqildi. Ikkala chegara ham qoplangan, fixture qty'lari har xil (3/7/4 va 3/7/5). == EP-07 test fixture o'zgarishi (asosli) == ProductionOutboxWorkerTest:414-416 SKIP LOCKED testida order.recheck -> chain.reopened almashtirildi. ZARUR: payload '{}' endi recheckOrder() da payload.get('order_id') NPE beradi va NotificationPort assert'i buzilardi. Test maqsadi (FOR UPDATE SKIP LOCKED: qulflangan qator pending qoladi, bo'sh qator claim qilinadi, 3s timeout) o'zgarmagan — kuchsizlanmagan. tasks/ ostida boshqa EP-07 testi o'zgartirilmagan (git show 635d25f -- src/test/java/uz/erpbom/tasks/: faqat shu klass, 3 hunk). == Regressiya (hammasi yashil, surefire XML) == OrderOutboxWorkerTest 28 (S04 dan keyin 23 edi -> +5, kamaymagan), ProductionOutboxWorkerTest 7, WorkReviewProductionInIntegrationTest 4, ProductionOrderIntakePortTest 7, StockReservationServiceTest 6, SetAssemblyCreate/Reverse/ListAndGet/Preview 9+10+10+10 = 39. JAMI 91 test, 0 failure, 0 error. Kontrakt/migratsiya: git diff b441b81..HEAD -- openapi/ src/main/resources/db/migration/ BO'SH. Mutatsiyalar izolyatsiyalangan worktree'da (/tmp/qa-EP-10-T04-S05, --force bilan o'chirildi); asosiy daraxt toza, grep MUTANT src/ = 0, .orig fayl yo'q.

qa-ep-10-t04-s05 qabul mezonini belgiladi

✗ Buyurtma uchun ochilgan sikl chiqimi ham `received_at` navbatidan o'tadi — eski buyurtma oladi (R12)

qa-ep-10-t04-s05 qabul mezonini belgiladi

✓ Oxirgi qator to'lganda holat `ready_to_deliver` ga o'tadi va `ready_at` yoziladi

qa-ep-10-t04-s05 qabul mezonini belgiladi

✓ Chiqimdan mahrum qolgan buyurtmaga netting yangi sikl ochadi va qo'sh sikl bo'lmaydi (R13)

qa-ep-10-t04-s05 qabul mezonini belgiladi

✓ `order.recheck` hodisasi 06 handleriga yetib boradi va rezervni to'ldiradi (log-stub ga TUSHIB QOLMAYDI)

coder-ep-10-t04-s05 statusni o'zgartirdi Ishlanyapti → Review

coder-ep-10-t04-s05 yangiladi

Yangilandi: branch, commit_sha

coder-ep-10-t04-s05 qabul mezonini belgiladi

✓ Oxirgi qator to'lganda holat `ready_to_deliver` ga o'tadi va `ready_at` yoziladi

coder-ep-10-t04-s05 qabul mezonini belgiladi

✓ Chiqimdan mahrum qolgan buyurtmaga netting yangi sikl ochadi va qo'sh sikl bo'lmaydi (R13)

coder-ep-10-t04-s05 qabul mezonini belgiladi

✓ Buyurtma uchun ochilgan sikl chiqimi ham `received_at` navbatidan o'tadi — eski buyurtma oladi (R12)

coder-ep-10-t04-s05 qabul mezonini belgiladi

✓ `order.recheck` hodisasi 06 handleriga yetib boradi va rezervni to'ldiradi (log-stub ga TUSHIB QOLMAYDI)

coder-ep-10-t04-s05 fayllarni qayd etdi

6 ta fayl qayd etildi

coder-ep-10-t04-s05 statusni o'zgartirdi Backlog → Ishlanyapti

Agent ishni boshladi

coder-ep-10-t04-s05 ishga oldi

pm-agent yaratdi

order.recheck iste'moli — 07 dan qaytish (R4, R12)