Infra qatlamlari — Caffeine kesh, outbox worker naqshi, @Scheduled cron

team-lead-pm izoh qoldirdi

YOPILDI (foydalanuvchi qarori, 2026-08-17): outbox muvaffaqiyat holati = 'sent'. 00_CROSS_CUTTING.md §F.2 va §F.10 tuzatildi (ilgari 'done' derdi — xato edi; 10_notifications §2/§4 allaqachon pending|sending|sent|failed|dead deb belgilagan). Kod o'zgarmaydi, AC 112 to'g'ri edi. notification_outbox migratsiyasi hali yozilmagan — ma'lumot migratsiyasi yo'q.

finalize-ep-01 yangiladi

Yangilandi: pr_url

finalize-ep-01 yangiladi

Yangilandi: branch, commit_sha

team-lead-pm izoh qoldirdi

PM qaydi: QA topgan spec-kod nomuvofiqligi — 00_CROSS_CUTTING.md §F.2 outbox muvaffaqiyat holati 'done', kod/AC esa 'sent'. Doc o'zgarishi (CLAUDE.md §5 sikli) yoki kod tuzatishi bilan yopiladi; muddat — notification_outbox migratsiyasidan OLDIN (10_notifications epici). Hozir bloker emas: jadval hali yo'q.

qa-1 statusni o'zgartirdi Review → Bajarildi

QA: 8/8 mutatsiya ushlandi, mvn -B verify yashil (63 test), spec §F va scope muvofiq.

qa-1 izoh qoldirdi

QA (qa-1) yakuniy tekshiruv — O'TDI. == Mutatsion tekshiruv (QA O'ZI yurgizdi; har biridan keyin `git checkout` bilan tiklandi) — 8/8 ushlandi == 1. `FOR UPDATE SKIP LOCKED` -> `FOR UPDATE`: AbstractOutboxWorkerTest#skipLockedAllowsClaimingUnlockedRow... QIZIL (execution timed out after 2000 ms) 2. qulf bandi BUTUNLAY olib tashlandi: o'sha test QIZIL (UPDATE qulflangan qatorda bloklanadi) — timeout 3. CacheConfig: nomlangan kesh `toBuilder(spec)` -> `toBuilder(defaults)`: namedCacheReadsTtlAndMaximumSizeFromConfiguration QIZIL (60s kutilgan) 4. CacheConfig: `@ConditionalOnProperty` olib tashlandi: cacheTypeNoneFallsBackToNoOp... QIZIL (NoOpCacheManager o'rniga bizniki qoldi) 5. SchedulingConfig: `@EnableScheduling` olib tashlandi: SchedulingConfigTest QIZIL (ConditionTimeout — @Scheduled yurmadi) 6. backoff `Math.pow(multiplier, attempts-1)` -> `1.0`: failingRowRetriesWithExponentialBackoff... QIZIL (kechikish o'smadi) 7. `newAttempts >= maxAttempts` -> `>`: o'sha test QIZIL (max_attempts ga yetgach 'failed' bo'lmadi) 8. claim WHERE ga `'sent'` qo'shildi: successfulRowIsMarkedSentAndNeverReclaimed QIZIL Har mutatsiyada FAQAT tegishli test qizil bo'ldi — assertlar tavtologik emas. AC 110 endi haqiqatan `SKIP LOCKED` ga bog'liq: avvalgi CyclicBarrier versiyasi 1/2-mutatsiyada yashil qolardi, yangi test (alohida JDBC ulanishida commit qilinmagan FOR UPDATE qulfi + 2s preemptive timeout) ikkalasini ham ushlaydi. Coder da'vosi tiklandi. == Build == `flock /var/tmp/erpbom-db.lock -c "mvn -B verify"` -> BUILD SUCCESS; Tests run: 63, Failures: 0, Errors: 0, Skipped: 0. == Spec muvofiqligi (CROSS_CUTTING §F) == F.2 har qator alohida tranzaksiyada yopiladi ✓ · F.3 attempts++/eksponensial next_attempt_at/last_error, sukut maxAttempts=10 ✓, alohida sweeper yo'q — lease muddati o'tgan `processing` qatorni worker o'zi qayta oladi ✓ (ikkala yo'nalishga test bor) · F.4 at-least-once ✓ · F.10 tashqi chaqiruv qulf ostida EMAS ✓ (claim tranzaksiyasi commit bo'lgach `process()` chaqiriladi) · AR-3/AR-4/AR-12: broker/kesh serveri/ShedLock yo'q, buni AC 113 pom testi qo'riqlaydi. == Cross-cutting == tenant_id / schema almashtirish izi yo'q (AR-1) · fizik DELETE yo'q · parol/token log'ga yozilmaydi · migratsiya/numeric ustun bu bargda yo'q (N/A). Tranzaksiya chegarasi `@Transactional` emas, `TransactionTemplate` bilan — sabab (self-invocation `runOnce()`->`claimBatch()` proksida tashlab ketiladi) javadocda asoslangan, to'g'ri qaror. == Scope == `git show --stat f6763d6` va `4f41f29`: faqat common/cache, common/outbox, common/config/SchedulingConfig va application.yml (kesh bloki). Boshqa agentlar fayllariga (S03/S04/kontrakt) aralashmagan. == ⚠️ PM ga eslatma (bu bargni bloklamaydi, keyingi epicga) == (a) CROSS_CUTTING §F.2 muvaffaqiyat holatini `status = 'done'` deb yozadi, AC 112 va kod esa `'sent'` ishlatadi. Hozir konkret outbox jadvali yo'q (faqat abstrakt naqsh) — ta'siri nol. Lekin birinchi HAQIQIY jadval (`notification_outbox`, 10_notifications) migratsiyasidan OLDIN doc yoki AC moslashtirilsin, aks holda status CHECK constraint naqsh bilan to'qnashadi. (b) `markFailedAttempt` istisno matnini `last_error` ga (2000 belgi) yozadi va `log.warn` istisnoni to'liq log'ga chiqaradi — konkret worker'lar (FCM/HTTP) istisno matniga token/parol tushirmasligi kerak.

qa-1 qabul mezonini belgiladi

✓ Repo'da RabbitMQ/Redis/ShedLock bog'liqligi yo'q; `mvn -q verify` yashil

qa-1 qabul mezonini belgiladi

✓ Muvaffaqiyatli yozuv `sent`, qayta olinmaydi (test)

qa-1 qabul mezonini belgiladi

✓ Xato → `attempts` oshadi va `next_attempt_at` eksponensial suriladi; `max_attempts` dan keyin `status='failed'` (test)

qa-1 qabul mezonini belgiladi

✓ Abstrakt outbox worker: 2 parallel worker instansi bitta yozuvni ikki marta olmaydi (`SKIP LOCKED` testi)

qa-1 qabul mezonini belgiladi

✓ `CacheManager` bean mavjud, nomlangan kesh TTL konfiguratsiyadan o'qiladi; kesh o'chirilganda (`spring.cache.type=none`) ilova baribir to'g'ri ishlaydi (test)

coder-ep-01-t01-s05 statusni o'zgartirdi Ishlanyapti → Review

coder-ep-01-t01-s05 statusni o'zgartirdi Tayyor → Ishlanyapti

Agent ishni boshladi

coder-ep-01-t01-s05 ishga oldi

coder-ep-01-t01-s05 izoh qoldirdi

AC110 tuzatildi: eski CyclicBarrier testi olib tashlandi, o'rniga skipLockedAllowsClaimingUnlockedRowWhileAnotherRowIsLockedElsewhere — test o'zi alohida JDBC ulanishida bitta qatorni FOR UPDATE bilan qulflab COMMIT qilmasdan ushlab turadi, keyin assertTimeoutPreemptively(2s) ichida worker.runOnce() bo'sh qatorni claim qilishini kutadi. Qo'lda mutatsiya bilan tasdiqladim (keyin git checkout bilan tikladim): 'FOR UPDATE SKIP LOCKED'->'FOR UPDATE' va butunlay olib tashlash — ikkalasida ham AbstractOutboxWorkerTest TIMEOUT bilan qizil (boshqa testlarga ta'sirsiz), original kodga qaytarilgach mvn verify 55/55 yashil. Qo'shimcha: CROSS_CUTTING F.3 lease-qayta-olish uchun 2 test (abandonedProcessingRowIsReclaimedAfterLeaseTimeoutExpires, processingRowWithinLeaseIsNotReclaimed) va OutboxWorkerConfigTest (defaults() + validatsiya) qo'shdim. 'sent' nomiga tegmadim (PM/team-lead darajasidagi masala).

coder-ep-01-t01-s05 qabul mezonini belgiladi

✓ Abstrakt outbox worker: 2 parallel worker instansi bitta yozuvni ikki marta olmaydi (`SKIP LOCKED` testi)

coder-ep-01-t01-s05 fayllarni qayd etdi

2 ta fayl qayd etildi

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

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-01-t01-s05 statusni o'zgartirdi Review → Ishlanyapti

qa-ep-01-t01-s05 izoh qoldirdi

QA (qa-EP-01-T01-S05) — QAYTARILDI. 5 mezondan 4 tasi o'tdi, AC 110 yiqildi. Baza: mvn -B verify = 48 test, 0 failure, BUILD SUCCESS (toza daraxtda, HEAD=7b25859). Mutatsiya tekshiruvidan keyin fayllar git checkout bilan aynan tiklandi, git status bo'sh. === ✗ AC 110 — test konkurentlikni QO'RIQLAMAYAPTI (yagona blokerchi) === Fayl: src/test/java/uz/erpbom/common/outbox/AbstractOutboxWorkerTest.java:107-155 (twoParallelWorkersNeverProcessTheSameRowTwice) Prod: src/main/java/uz/erpbom/common/outbox/AbstractOutboxWorker.java:133-151 (claimBatch), 142-qator = FOR UPDATE SKIP LOCKED Mutatsiya natijalari (mvn -o test -Dtest=AbstractOutboxWorkerTest): M1) 142-qator `FOR UPDATE SKIP LOCKED` -> `FOR UPDATE` => 4/4 urinish YASHIL. Test SKIP LOCKED yo'qolganini UMUMAN sezmaydi. M2) 142-qator butunlay olib tashlandi (hech qanday qulf yo'q) => klass bo'yicha yurgizilganda (mvn verify shu yo'ldan boradi) 3/4 urinish YASHIL, faqat 1 tasi qizil; yolg'iz metod sifatida yurgizilganda 3/3 qizil. Ya'ni qulflash mexanizmini butunlay yo'q qilsa ham CI yashil qolaveradi — bu test tanga tashlash. Sabab (ikkita, ikkalasi ham tuzatilishi kerak): 1. CyclicBarrier faqat runOnce() BOSHLANISHINI sinxronlaydi. Claim SQL ~1 ms — A worker odatda o'z claim tranzaksiyasini B ning SELECT'i snapshot olishidan oldin COMMIT qilib ulguradi. Kesishuv yuz bermaydi => hech narsa isbotlanmaydi. 2. Sof `FOR UPDATE` (SKIP LOCKED'siz) bilan ham natija AYNAN bir xil bo'ladi: B bloklanadi, A commit qilgach EvalPlanQual qayta tekshiruvi qatorni (status endi 'processing') filtrdan chiqaradi va B 0 qator oladi. Demak hozirgi assert'lar SKIP LOCKED ni printsipial jihatdan ajrata OLMAYDI — timing masalasi emas, konstruksiya masalasi. Talab qilinadigan tuzatish — determinstik test (poyga emas, qulfni testning O'ZI ushlab tursin): 1. 2 qator qo'y (row1 eskiroq), batchSize=1. 2. Testda ALOHIDA JDBC Connection och, setAutoCommit(false), bajar: SELECT id FROM outbox_worker_test WHERE status='pending' ORDER BY created_at LIMIT 1 FOR UPDATE -> row1 qulflandi, COMMIT QILMA. 3. Qulf ushlab turilgan holda: assertTimeoutPreemptively(Duration.ofSeconds(2), () -> worker.runOnce()) — natija 1 bo'lsin va claim qilingan/process qilingan id AYNAN row2 bo'lsin. -> SKIP LOCKED yo'q bo'lsa: runOnce row1 da bloklanadi -> timeout -> QIZIL. -> FOR UPDATE yo'q bo'lsa: row1 ham claim qilinadi -> id assert -> QIZIL. 4. Ushlab turgan ulanishni commit/rollback qil; ikkinchi runOnce() -> row1 claim qilinsin, row2 QAYTA process qilinmasin (ikkilanish yo'q). Tugatgach M1 va M2 mutatsiyalarini O'ZING qayta yurgiz — IKKALASI HAM qizil bo'lishi shart. Bu naqsh 06/10 modullarga meros bo'ladi, shuning uchun qat'iy. === ✓ O'tgan mezonlar (mustaqil mutatsiya bilan tasdiqlangan) === AC 109: TTL config'dan — CacheConfig.java:46-50 dagi spec.getTtl()/getMaximumSize() ni qat'iy qiymatga almashtirdim -> test QIZIL ✓. @ConditionalOnProperty (CacheConfig.java:37) ni olib tashladim -> spring.cache.type=none testi QIZIL ✓. AC 111: eksponensial formulani (AbstractOutboxWorker.java:176-181) qat'iy kechikishga almashtirdim -> QIZIL ✓. Chegara `newAttempts >= maxAttempts` (163-qator) ni +1 ga surdim -> failed o'tish testi QIZIL ✓. AC 112: claim filtridan `status='pending'` (138-qator) ni olib tashladim -> successfulRowIsMarkedSentAndNeverReclaimed QIZIL ✓. AC 113: mustaqil tekshirdim — mvn -o dependency:tree (148 qator) da rabbitmq/amqp/redis/jedis/lettuce/shedlock YO'Q; mvn verify yashil ✓. === Regress — toza === * src/main/resources/db/migration/ da faqat V1__baseline.sql; S02 dan beri bayt-bayt o'zgarmagan (git diff 55158d6..HEAD -- src/main/resources/db/migration/ bo'sh). Namuna outbox jadvali faqat testda, oddiy JDBC bilan (AbstractOutboxWorkerTest.java:72-85). S02 AC 94 buzilmagan ✓ * ErpbomBackendApplication.java ga f6763d6 tegmagan (oxirgi teккan commit — 58820f0/S02); @EnableScheduling alohida common/config/SchedulingConfig.java:23 da ✓ * S03 fayllariga (common/{exception,web,filter,dto}, JacksonConfig, log pattern) tegilmagan ✓ === Bloklamaydigan eslatmalar (tuzatish tavsiya, qaytarish sababi EMAS) === N1. AC 109 ning `spring.cache.type=none` testi (CacheConfigTest.java:66-81) to'liq ilovani emas, ApplicationContextRunner slice'ini ko'taradi. Assert'lar haqiqiy (mutatsiya o'ldirdi), shuning uchun qabul qildim; to'liq isbot kerak bo'lsa SPRING_CACHE_TYPE=none bilan @SpringBootTest qo'shiladi. N2. OutboxWorkerConfig.defaults() dagi maxAttempts=10 (OutboxWorkerConfig.java:67) birorta test bilan tasdiqlanmagan — AC 111 dagi "default 10" faqat kodni o'qish bilan tekshirildi. Bir qatorlik unit assert yopadi. N3. Lease qayta olish tarmog'i (AbstractOutboxWorker.java:139, `status='processing' AND locked_at <= ?`) — CROSS_CUTTING §F.3 ning "sweeper yo'q" mexanizmi — umuman testsiz. Har modul shuni meros oladi; AC 110 testini yozayotganda shuni ham qo'shish arzon. N4. PM uchun (kod emas): CROSS_CUTTING §F.2 muvaffaqiyat holatini `status = 'done'` deydi, AC 112 va kod esa `'sent'` ishlatadi. Bu bargni bloklamaydi (AC ustun, `sent_at` va `notification_outbox` bilan mos), lekin 10_notifications epicidan oldin doc bilan kod moslanishi kerak.

qa-ep-01-t01-s05 qabul mezonini belgiladi

✗ Abstrakt outbox worker: 2 parallel worker instansi bitta yozuvni ikki marta olmaydi (`SKIP LOCKED` testi)

qa-ep-01-t01-s05 qabul mezonini belgiladi

✓ Repo'da RabbitMQ/Redis/ShedLock bog'liqligi yo'q; `mvn -q verify` yashil

qa-ep-01-t01-s05 qabul mezonini belgiladi

✓ Muvaffaqiyatli yozuv `sent`, qayta olinmaydi (test)

qa-ep-01-t01-s05 qabul mezonini belgiladi

✓ Xato → `attempts` oshadi va `next_attempt_at` eksponensial suriladi; `max_attempts` dan keyin `status='failed'` (test)

qa-ep-01-t01-s05 qabul mezonini belgiladi

✓ `CacheManager` bean mavjud, nomlangan kesh TTL konfiguratsiyadan o'qiladi; kesh o'chirilganda (`spring.cache.type=none`) ilova baribir to'g'ri ishlaydi (test)

coder-ep-01-t01-s05 izoh qoldirdi

CacheConfig — CaffeineCacheManager, erpbom.cache.defaults/caches (nomlangan kesh TTL/hajmi config'dan); spring.cache.type=none bo'lsa bean o'chadi, Boot NoOpCacheManager'ga qaytadi (AR-4). AbstractOutboxWorker — TransactionTemplate bilan dasturiy tranzaksiya (self-invocation muammosidan qochish uchun @Transactional emas): claim (bitta atomik UPDATE...FROM(SELECT...FOR UPDATE SKIP LOCKED)), process() qulfsiz, finalize alohida tranzaksiyada. Test uchun outbox_worker_test jadvali FAQAT test doirasida (oddiy JDBC bilan), src/main/resources/db/migration ga tegilmadi (S02 AC94 buzilmadi). AC110 testi haqiqiy parallellik: CyclicBarrier bilan 2 thread bir vaqtda claim'ga uradi, har qator process() aynan 1 marta chaqirilgani ConcurrentHashMap counter bilan tekshiriladi. AC111: backoff Java'da hisoblanadi (initialBackoff*multiplier^(attempts-1)), test 2-kechikish/1-kechikish nisbatini sozlangan multiplier'ga solishtiradi. mvn verify: 37/37 yashil (S02/S03 testlari bilan birga). dependency:tree'da rabbitmq/redis/jedis/lettuce/shedlock yo'q.

coder-ep-01-t01-s05 statusni o'zgartirdi Ishlanyapti → Review

coder-ep-01-t01-s05 qabul mezonini belgiladi

✓ Repo'da RabbitMQ/Redis/ShedLock bog'liqligi yo'q; `mvn -q verify` yashil

coder-ep-01-t01-s05 qabul mezonini belgiladi

✓ Muvaffaqiyatli yozuv `sent`, qayta olinmaydi (test)

coder-ep-01-t01-s05 qabul mezonini belgiladi

✓ Xato → `attempts` oshadi va `next_attempt_at` eksponensial suriladi; `max_attempts` dan keyin `status='failed'` (test)

coder-ep-01-t01-s05 qabul mezonini belgiladi

✓ Abstrakt outbox worker: 2 parallel worker instansi bitta yozuvni ikki marta olmaydi (`SKIP LOCKED` testi)

coder-ep-01-t01-s05 qabul mezonini belgiladi

✓ `CacheManager` bean mavjud, nomlangan kesh TTL konfiguratsiyadan o'qiladi; kesh o'chirilganda (`spring.cache.type=none`) ilova baribir to'g'ri ishlaydi (test)

coder-ep-01-t01-s05 fayllarni qayd etdi

12 ta fayl qayd etildi

coder-ep-01-t01-s05 statusni o'zgartirdi Backlog → Ishlanyapti

Agent ishni boshladi

coder-ep-01-t01-s05 ishga oldi

pm-agent bog'liqlik qo'shdi

→ EP-01-T01-S02

pm-agent yaratdi

Infra qatlamlari — Caffeine kesh, outbox worker naqshi, @Scheduled cron