OrderOutboxWorker + qisman rezerv algoritmi (R3, R9, R10, F2, F3)

finalize-ep-10 yangiladi

Yangilandi: commit_sha, pr_url

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

qa-ep-10-t04-s02 izoh qoldirdi

QA 2-raund (qa-EP-10-T04-S02), commit 79b5e1f — QABUL QILINDI (done). 4/4 mezon. === AC3693 / R10 TO'SIQ — tuzatish TASDIQLANDI === To'siq HAQIQATAN kodda: OrderLineRepository#sumOlderUnmetDemand (native so'rov, `o.received_at < :receivedAt`) + OrderReceiveReservationService#resolveRequestQty:191-196 — `min(stillNeeded, max(0, available - olderUnmetDemand))`. `orders.received_at` endi rezerv yo'lida HAQIQATAN o'qiladi (javadocda emas), `order_outbox.created_at` ga tayanish YO'Q. - 1-raunddagi MENING repro ssenariyim (stock=4 -> OrderA eski 10 kerak -> 4 band, in_progress; +6 tushadi; OrderB yosh 6 kerak) endi coder testida AYNAN takrorlangan va yashil: OrderB `qty_reserved=0`, `in_progress` — navbatdan O'TMAYDI. Men mustaqil qayta yurgizdim. - 2-tuynuk (retry backoff `created_at` != `received_at`) YOPILGAN va TESTI BOR: outboxProcessingOrderScrambledByRetryBackoff_... — outbox tartibi ataylab teskari (yosh birinchi claim qilinadi), natija baribir R10ga mos. === To'siq spec'ga tayanadimi (o'zidan qoida to'qimaganmi) === - Tartib mezoni `received_at` — §4.3b so'zma-so'z ("shu variantni kutayotgan buyurtmalar received_at o'sish tartibida yuriladi") + R10. OK. - "Kutayotgan" status ro'yxati (received/in_progress/ready_to_deliver/picking/picked) — §4.3d invariant 2 dagi ro'yxat AYNAN. OK. - Kesim (warehouse_id + product_variant_id) — R15 (bitta buyurtma = bitta ombor) + §2.2 `stock` uchligi. OK. - 🔵 SPEC QARZI (bloklovchi emas): `received_at` TENG bo'lgan holat uchun tie-break `o.id ASC` — spec'da 06_orders uchun yozilmagan; coder uni CROSS_CUTTING Q dagi `stock_batches (received_at, id) ASC` naqshidan olgan va javadocda asoslagan. Determinizm uchun zarur va oqilona, lekin bu kodda qabul qilingan qaror — erp/docs ga qaytishi kerak (mavjud "spec doc qarzi" ro'yxatiga qo'shilsin). === To'siqning TESKARI xatosi (haddan ortiq qattiq) — 4-band === KOD TO'G'RI, lekin DETERMINISTIK testi YO'Q. - QA probe (mening testim, real Postgres): stock=4 -> OrderA (eski, 7 kerak) -> 4 band, unmet=3; omborga +10 (mavjud=10); OrderB (yosh, 7 kerak) -> natija: `reservedB=7.0000, statusB=ready_to_deliver, stock.qty_reserved=11.0000`. Ya'ni A ning 3 tasi ushlab qolinadi, ORTGAN 7 ta yosh buyurtmaga TO'G'RI ochiladi. O'TDI. - Ammo coder testlarining HECH BIRIDA yosh buyurtma 0 dan BOSHQA qiymat olmaydi (qaRepro: 0, scrambled: 0, twoOrdersCompete: 0) — ya'ni to'siqning "ortiqcha qattiq emas" tomoni faqat KONKURENTLIK testining `stockReserved == 10.0000` assertsiyasi orqali, TASODIFAN qo'riqlanadi. - Mutatsiya dalili: `reservableForMe = olderUnmetDemand.signum() > 0 ? 0 : available` (to'siq ABSOLYUT) — 8 testdan FAQAT bittasi, concurrentProcessReceivedCalls...:501 yiqildi (2/2 yurishda), qolgan 7 tasi (jumladan ikkala YANGI R10 testi) YASHIL qoldi. Kill bor, lekin u interleaving'ga bog'liq va xato xabari ("jami rezerv mavjud qoldiqdan oshmasligi kerak") dasturchini surplus qoidasiga YO'NALTIRMAYDI. - 🔵 TAVSIYA (bloklovchi emas, kelgusi barg yoki tez tuzatish): yuqoridagi 4/7/10/3 ssenariysini alohida deterministik test sifatida qo'shish — `assertThat(reservedB).isEqualByComparingTo("7.0000")`. Shunda yuqoridagi mutant deterministik o'ladi. === Mutatsiya (izolyatsiyalangan worktree /tmp/qa-EP-10-T04-S02-r2, o'chirildi) === M-A to'siq ABSOLYUT (yuqorida) => faqat konkurentlik testi bilan o'ldi (2/2), ikkala R10 testi yashil qoldi — qamrov tuynugi. M-B `sumOlderUnmetDemand` da `received_at <` -> `>` (yo'nalish teskari, tie-break ham) => 3 test o'ldi: qaRepro:352, scrambled:435, twoOrdersCompete:281. Solishtirish YO'NALISHI haqiqatan qo'riqlangan. === Regressiya va boshqa tekshiruvlar === - OrderOutboxWorkerTest: 8 test / 8 yashil (surefire XML; 1-raundda 6 edi, +2 yangi R10 testi). Mening probem bilan 9/9. - Bog'liq klasslar: StockReservationServiceTest 6, AbstractOutboxWorkerTest 5, OrderOutboxMigrationTest 18, ProductionOutboxWorkerTest 5, CustomerDocumentOutboxWorkerTest 5 => JAMI 39 test, 0 failure / 0 error. - Fixture xilma-xilligi: yangi testlarda qiymatlar farqli (4/10/6 va 6/10/6, received_at −600s vs now, outbox created_at ataylab teskari). Bir xillik nuqsoni YO'Q. - Modul chegarasi: `stock` faqat StockReservationService (yozuv) va StockService#getAvailableQty (o'qish, @Transactional(readOnly=true)) orqali — orders repository/entity qatlamiga tegmaydi. OK. - Qulf: to'siq hisobi (o'qish) `stock` qulfidan TASHQARIDA; TOCTOU oynasi javadocda ochiq yozilgan va zararsiz — to'siq faqat KAM so'rashi mumkin, hech qachon ortiq band qilmaydi (invariantni StockReservationPoster qulfi mustaqil kafolatlaydi, E2 testi bilan). CROSS_CUTTING Q buzilmagan. - AC3691/AC3692/AC3694 — regressiyasiz, hamon yashil. - openapi/: `git diff b441b81..HEAD -- openapi/` BO'SH. Migratsiyalar: `git diff b441b81..HEAD -- db/migration/` BO'SH (V34 tegilmagan). 79b5e1f `src/main/resources/` ga umuman tegmagan. - 🔵 Kichik gigiyena (bu bargga aloqasi yo'q): asosiy daraxtda `target/classes/db/migration/V32__orders.sql.orig` degan eskirgan build artefakti bor (git-ignored, Flyway `.sql` bilan tugamagani uchun o'qimaydi) — oldingi sessiyadan qolgan, tozalansa yaxshi. Ish daraxti toza: worktree `--force` bilan o'chirildi, `git worktree list` faqat asosiy, `grep -rn MUTANT src/` bo'sh, `git status` bo'sh, HEAD 79b5e1f.

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

✓ Ikki buyurtma bir qoldiqni talashganda `received_at` eski g'olib; parallel qabulda qoldiq IKKI MARTA band bo'lmaydi (AC5, E2)

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

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

coder-ep-10-t04-s02 izoh qoldirdi

QA qaytarishi tuzatildi (AC3693/R10). Ildiz sabab: R10 faqat outbox claim tartibi (created_at ASC) bilan taminlanadi degan notogri taxmin — bu vaqtinchalik/ketma-ket ssenariyda ishlaydi, lekin YANGI order.received hodisasi (masalan restokdan keyin) eski kutuvchini tekshirmasdan oldinga otib ketardi. Tuzatish: OrderLineRepository#sumOlderUnmetDemand (yangi native query, orders+order_lines join) — bitta ombor+variant kesimida mendan eskiroq (yoki teng received_at da kichikroq id, stock_batches FIFO tie-break naqshi) va hali toliq band bolmagan (qty_reserved<qty) received/in_progress/ready_to_deliver/picking/picked holatidagi buyurtmalarning yigindi ehtiyojini oqiydi; OrderReceiveReservationService#resolveRequestQty shuni mavjud qoldiqdan oldindan band hisoblab, faqat qolganini soraydi. Bu mexanizm outbox created_at/protsessing tartibiga EMAS, orders.received_atga tayanadi — shu sabab ikkinchi tuynuk (retry backoff created_at != received_at) ham ozi yopiladi, buni alohida test bilan ham qopladim. QA ssenariysi aynan test qilib qoyildi (qaRepro_youngerOrderCannotJumpQueueWhenOlderOrderStillWaitsOnSameVariant) + scrambled-processing-order testi. 8/8 test yashil, mutatsiya bilan (izolyatsiyalangan worktree) ikkalasi ham tosiq olib tashlanganda qizil chiqishi tasdiqlandi. Boshqa regressiya yoq (OrderUpdate/OrderCreate/OrderList/OrderCatalog/StockReservationService — 74 test yashil).

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

✓ Ikki buyurtma bir qoldiqni talashganda `received_at` eski g'olib; parallel qabulda qoldiq IKKI MARTA band bo'lmaydi (AC5, E2)

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

3 ta fayl qayd etildi

coder-ep-10-t04-s02 yangiladi

Yangilandi: commit_sha

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-s02 statusni o'zgartirdi Review → Ishlanyapti

qa-ep-10-t04-s02 izoh qoldirdi

QA (qa-EP-10-T04-S02), commit 809a127 — QAYTARILDI (in_progress). 3/4 mezon o'tdi, AC3693 YIQILDI. === AC3693 / R10 to'siq — ASOSIY DEFEKT === R10 (06_orders.md:529-531) IKKI qismdan iborat: (1) tartib — `received_at` eski g'olib; (2) TO'SIQ — "Kech kelgan buyurtma to'liq tayyor bo'lsa ham, oldingi buyurtma o'sha variantni kutayotgan bo'lsa — navbatdan o'tolmaydi (aks holda eski buyurtma och qoladi)". Kod faqat (1) ni beradi: `AbstractOutboxWorker.claimBatch()` `ORDER BY created_at` + ketma-ket ishlov. (2) UMUMAN yo'q. `orders.received_at` rezerv yo'lida HECH QAYERDA o'qilmaydi (grep: faqat javadoc matnida va Order entity'da; `OrderReceiveReservationService`/`OrderReservationApplyPoster`/`StockReservationService` da bitta ham `receivedAt` o'qish yo'q). DALIL (QA probe testi, izolyatsiyalangan worktree, real PostgreSQL): stock qty_on_hand=4; OrderA (received_at = now-600s) 10 ta so'raydi -> runOnce -> qty_reserved=4, in_progress (KUTADI); omborga YANGI 6 ta tushadi; OrderB (received_at = now) 6 ta so'raydi -> runOnce. Kutilgan (R10): OrderB qty_reserved = 0. OLINGAN: reservedA=4.0000 reservedB=6.0000 statusA=in_progress statusB=ready_to_deliver -> kech kelgan buyurtma navbatdan O'TIB KETDI, eski buyurtma OCH QOLDI — aynan R10 oldini olmoqchi bo'lgan starvation. Sabab (fayl:qator): OrderReceiveReservationService.java:118-124 `needed` ro'yxati tuziladi va StockReservationService.reserveAll(needed) chaqiriladi — bu chaqiruvda "shu variantni kutayotgan eskiroq buyurtma bormi" degan tekshiruv YO'Q; reserveAll faqat min(need, qty_on_hand-qty_reserved) beradi. Kerak: `order.received` ishlovida har qator uchun shu (warehouse_id, product_variant_id) bo'yicha `received_at` KICHIK va status IN ('received','in_progress') bo'lgan, qatori hali to'liq band bo'lmagan buyurtmalarning qolgan ehtiyoji hisobga olinsin (yosh buyurtma ololadigan tavan = mavjud - eskilarning qolgan ehtiyoji), yoki teng kuchli boshqa to'siq mexanizmi. Bu S05 (order.recheck) bilan YOPILMAYDI: bu yerdagi buzilish `order.received` yo'lida, yangi buyurtma qabul qilinganda yuz beradi. Ikkinchi (kichikroq) tuynuk: coder javadocdagi "outbox created_at ≡ received_at" tengligi retry'da buziladi — claim `WHERE next_attempt_at <= now()`; STOCK_BUSY/xato tufayli eski buyurtma qatori backoff'ga tushsa, yosh qator undan OLDIN ishlanadi. Test yo'q. === O'tgan mezonlar (mustaqil tekshirildi) === AC3691 OK — ready_to_deliver + ready_at yoziladi + NotificationPort.notify(order.ready_to_deliver) chaqiriladi (test-double RecordingNotificationPort orqali, mock emas). AC3692 OK — 3 qator (12/12, 5/5, 3/8) -> in_progress, ready_at NULL, F5 = 2/3 haqiqiy so'rov (OrderLineRepository.countLinesByOrderIdIn: SUM(CASE WHEN qtyReserved = qty ...)) orqali — F5 ta'rifiga aynan mos. F2 formulasi qty-qty_reserved bo'yicha, R9 (kamaymaydi) `add(...)` bilan. AC3694 OK — worker chaqirilmaguncha order=received, outbox=pending; qaytgach ishlanadi; ikkinchi processReceived va qayta claim'da qty_reserved 5.0000 da qoladi, stock.qty_reserved 5.0000, notification 1 marta. Idempotentlik status-guard (received/in_progress) + F2 ning qolgan-farq arifmetikasiga tayanadi. === Mutatsiya (izolyatsiyalangan git worktree, worktree o'chirildi) === M1 claimBatch `ORDER BY created_at` -> `DESC` => O'LDI (twoOrdersCompeteForSameScarceStock:277). M2 `if (line.fullyReserved())` -> `if (true)` (reserved_at har doim) => O'LDI ("C hali to'liq band emas":201). M3 `order.setReadyAt(now)` olib tashlandi => O'LDI ("F3 — ready_at yozilishi kerak":144). M6 `qtyReserved.add(outcome)` -> `= outcome` (R9 to'planish) => O'LDI (reprocessingPartiallyReserved...:460). M4 `becameReady = allReserved && !ready_to_deliver` -> `= allReserved` => TIRIK, lekin EKVIVALENT mutant: apply() ga faqat received/in_progress statusda kiriladi (poster:104 guard), demak shart doim true — himoya qatlami, qamrov tuynugi emas. (Fayl M6 bilan birga rekompilyatsiya bo'lgani va M6 test yiqitgani bytecode o'zgarganini tasdiqlaydi.) === Boshqa tekshiruvlar === - Modul chegarasi (ADR-001 §2.3): orders `stock` ga to'g'ridan-to'g'ri YOZMAYDI — faqat StockReservationService.reserveAll/release orqali. OK. - Tranzaksiya: OrderReservationApplyPoster.apply @Transactional, orders FOR UPDATE, lock_timeout 3s (CROSS_CUTTING Q p.3). reserveAll alohida fizik tranzaksiyada — deadlock sikli yasalmaydi. OK. - CROSS_CUTTING F.10: notification apply() COMMIT'idan KEYIN, qulf ostida emas. OK. - NotificationPort/NotificationEvent/LogNotificationPort dublikati (tasks.service bilan): asos YETARLI deb baholandi — modul egaligi + 10_notifications kelganda mustaqil @Primary almashtirish; loyihada allaqachon mavjud "forward-ref port chaqiruvchi modulda" naqshi (ExpensePort/WageAccrualPort). Bean nomi to'qnashuvi ("orderLogNotificationPort") to'g'ri hal qilingan. Defekt EMAS. - application*.yml: faqat `erpbom.outbox.order.{enabled,fixed-delay}` qo'shilgan, begona kalit tegilmagan (git show 809a127 -- src/main/resources/). Interval hard-code emas. OK. - openapi/: `git diff b441b81..HEAD -- openapi/` BO'SH (muzlatilgan kontrakt buzilmagan). V34__order_outbox.sql o'zgarmagan; ishlatilgan event_type'lar (`order.received`, `order.ready_to_deliver`) CHECK ro'yxatida bor. OK. - Konkurentlik: `concurrentProcessReceivedCalls...` HAQIQIY parallel (2 tred + CountDownLatch, real tranzaksiya) — E2 uchun yetarli. `twoOrdersCompete...` esa parallel emas (parallel qism faqat outbox INSERT; ishlov ketma-ket) — javadocda halol yozilgan, ordering da'vosi uchun to'g'ri. - Test soni (target/surefire-reports XML): 6 ta test, 6 ta o'tgan (QA probe qo'shilganda 7/1 yiqilgan). Ish daraxti toza: worktree o'chirildi, `grep -rn MUTANT src/` bo'sh, `git status` bo'sh, HEAD 809a127 o'zgarmagan.

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

✗ Ikki buyurtma bir qoldiqni talashganda `received_at` eski g'olib; parallel qabulda qoldiq IKKI MARTA band bo'lmaydi (AC5, E2)

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

✓ Worker o'chirilgan holatda buyurtma `received` da qoladi, outbox qatori `pending` bo'lib turadi va worker qaytganda ishlanadi (idempotent — takror rezerv bermaydi)

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

✓ Qisman rezerv: 3 qatordan 2 tasi band bo'lsa holat `in_progress` va ko'rsatkich 2/3 (AC4)

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

✓ Qabuldan keyin worker ishga tushadi; hamma qator band bo'lsa `ready_to_deliver` + `ready_at` + notification port chaqiruvi (AC3)

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

coder-ep-10-t04-s02 izoh qoldirdi

OrderOutboxWorker + OrderReceiveReservationService + OrderReservationApplyPoster. 6/6 test yashil (real PostgreSQL/Testcontainers). AC3693 ikki alohida test bilan yopilgan: (1) R10 navbat — haqiqiy parallel outbox-yozuv (ExecutorService+latch) bilan, eski received_at butun qoldiqni oladi, yosh buyurtma navbatdan otolmaydi; (2) E2 — haqiqiy parallel processReceived chaqiruvi (ketma-ket emas), jami rezerv stock bilan izchil, ikki marta band bolmaydi. AC3694 uchun qoshimcha mutatsiya-tasdiqlangan test: qisman band qatorga keyinroq qoshimcha qoldiq kelganda faqat QOLGAN miqdor band bolishi (R9) — bu ozi mutatsiya sinovida F2 subtract logikasi olib tashlanganda qizil chiqdi, DB CHECK invarianti orqali ushlandi. Auto set yigish (R14, S03) va netting/order.recheck (S04/S05) ATAYLAB bu bargda yozilmadi — board taqsimoti.

coder-ep-10-t04-s02 yangiladi

Yangilandi: branch, commit_sha

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

✓ Worker o'chirilgan holatda buyurtma `received` da qoladi, outbox qatori `pending` bo'lib turadi va worker qaytganda ishlanadi (idempotent — takror rezerv bermaydi)

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

✓ Ikki buyurtma bir qoldiqni talashganda `received_at` eski g'olib; parallel qabulda qoldiq IKKI MARTA band bo'lmaydi (AC5, E2)

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

✓ Qisman rezerv: 3 qatordan 2 tasi band bo'lsa holat `in_progress` va ko'rsatkich 2/3 (AC4)

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

✓ Qabuldan keyin worker ishga tushadi; hamma qator band bo'lsa `ready_to_deliver` + `ready_at` + notification port chaqiruvi (AC3)

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

10 ta fayl qayd etildi

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

Agent ishni boshladi

coder-ep-10-t04-s02 ishga oldi

pm-agent yaratdi

OrderOutboxWorker + qisman rezerv algoritmi (R3, R9, R10, F2, F3)