Proxy upload — R42 ning 6 qadami va kompensatsiya

team-lead-ep-09 yangiladi

Yangilandi: pr_url

team-lead-ep-09 bog'liqlik qo'shdi

→ EP-09-T06-S01

team-lead-ep-09 yangiladi

Yangilandi: estimate_hours

team-lead-ep-09 statusni o'zgartirdi Ishlanyapti → Bajarildi

team-lead-ep-09 statusni o'zgartirdi Bloklangan → Ishlanyapti

team-lead-ep-09 izoh qoldirdi

Faza D drift 'topilmasi' kontrakt xatosi ekan, kod xatosi emas: T00 kontrakt agenti §2.8.3 dagi ilova-oqimi diagrammasini (GET /api/documents/{id}/download) literal endpoint deb noto'g'ri o'qigan edi. T06 backlog tavsifi (EP-09-T06 description) aniq: bu qayta ishlatiladigan komponent, 09_auth'ning o'z REST endpointi emas. Kontrakt tuzatildi (openapi/v1/auth.yaml dan /documents olib tashlandi, commit 0a058e2) -- kod o'zgarishsiz done.

finalize-ep-09 statusni o'zgartirdi Ishlanyapti → Bloklangan

DRIFT (finalize, oasdiff): kontrakt 'POST /api/v1/documents' (DocumentUploadRequest -> DocumentResponse) e'lon qilingan, lekin hech qanday controller bu yo'lni implement qilmagan (uz.erpbom.common.storage.FileUploadService bor, lekin REST controller yo'q — servis qatlami ulanmagan). Tuzatish: DocumentController (yoki mos nom) /api/v1/documents POST qo'shilsin, FileUploadService'ga bog'lansin, keyin finalize qayta drift tekshiruvi o'tkazsin.

finalize-ep-09 statusni o'zgartirdi Bajarildi → Ishlanyapti

Finalize drift tekshiruvi: openapi/v1/auth.yaml vs generatsiya qilingan /v3/api-docs — bu barg tugallanmagan (pastga qara). Blocked qilishdan oldin reopen.

qa-ep-09-t06-s02 statusni o'zgartirdi Review → Bajarildi

qa-ep-09-t06-s02 izoh qoldirdi

QA TASDIQLANDI (7/7 mezon). Kod: FileUploadService.java (2-6 qadam), KnownFileSignature.java (PDF/JPEG/PNG magic bytes), FileUploadProperties.java (@ConfigurationProperties erpbom.upload.*), FileTooLargeException/UnsupportedFileTypeException, StorageConfig.fileUploadService bean, application.yml erpbom.upload.max-size-bytes/allowed-mime-types. Test natijasi (flock ostida, jonli): mvn -Dtest=FileUploadServiceTest,KnownFileSignatureTest,FileUploadPropertiesTest,StorageConfigTest test -> Tests run: 27, Failures: 0, Errors: 0, BUILD SUCCESS. Mezon-mezon: 787 - requireAllowedMimeType -> readBounded -> requireMatchingSignature, barchasi storageClient.put() dan OLDIN chaqiriladi; oversizedFileThrowsFileTooLargeAndNeverTouchesStorage testi verifyNoInteractions(storageClient) bilan tasdiqlaydi. 788 - KnownFileSignature.matches() haqiqiy bayt sarlavhasini solishtiradi; contentNotMatchingDeclaredMimeSignatureThrowsUnsupportedFileTypeAndNeverTouchesStorage + allowedMimeTypeWithoutKnownSignatureFailsClosed (signaturasiz tur ham fail-closed 415) yashil. 789 - compensate() callback RuntimeException'da storageClient.delete(key) chaqiradi, asl xatoni qayta ko'taradi, delete o'zi xato bersa suppressed qiladi (ikkala test yashil). 790 - readNBytes IOException tashlasa storageClient bilan HECH qanday interaction bo'lmaydi (verifyNoInteractions) — obyekt yozilishidan oldin uzilgan oqim hech narsa qoldirmaydi. 791 - successfulUploadWritesToStorageAndInvokesCallbackWithStoredObject: StoredObject(file_key/mime_type/size_bytes) callback'ga to'g'ri uzatiladi. 792 - grep -rn upload_status: kodda faqat javadoc izohida ("YARATILMAYDI" deb) uchraydi — enum/ustun/cron yo'q. 793 - FileUploadProperties @ConfigurationProperties(prefix="erpbom.upload"), application.yml UPLOAD_MAX_SIZE_BYTES/UPLOAD_ALLOWED_MIME_TYPES env bilan sozlanadi, kodga qotirilmagan. MUTATSIYA TEKSHIRUVI (git checkout -- bilan qaytarildi): 1) KnownFileSignature.matches() ni doim true qaytaradigan qildim -> KnownFileSignatureTest 3 ta, FileUploadServiceTest 1 ta (jami 4) test qizil chiqdi. Tuzatildi. 2) FileUploadService.compensate() dagi storageClient.delete(key) chaqiruvini if(false) bilan o'chirdim -> ikkala kompensatsiya testi qizil chiqdi. Tuzatildi, qayta yashil tasdiqlandi (27/27). GIT TARIX ESLATMASI: S02 (efaecde) va parallel S03 (241828f) bir vaqtda GlobalExceptionHandler.java'ni tahrirlagan — S02'ning handleFileTooLarge/handleUnsupportedFileType metodlari 241828f commitida qolib ketgan, efaecde'da yo'q (git show --stat bilan tasdiqlandi). Kod working tree'da MAVJUD va ishlayapti — git tarix gigienasi masalasi, FUNKSIONAL DEFEKT EMAS, blokka olib kelmadi. T05/T08 fayllari (UserPermissionControllerIntegrationTest.java, SessionQueryRepository.java) ikkala commitga ham tushmagan. Cross-cutting: bu komponent DB entity/tranzaksiya/tenant_id/FK/outbox/precision/soft-delete bilan bevosita ishlamaydi (DB yozuvi ataylab chaqiruvchi domenga qoldirilgan) — N/A. compensate() dagi delete() — MinIO OBYEKTI uchun jismoniy o'chirish (R42 6-qadam talabi), DB qator emas — soft-delete qoidasini buzmaydi. Kichik kuzatuv (blok emas): kod MIME tekshiruvini (3-qadam) hajm tekshiruvidan (2-qadam) oldin bajaradi — R42 raqamlash tartibiga teskari, lekin javadoc'da ongli izohlangan va asosiy invariant (OMBORGA YOZISHDAN OLDIN) buzilmaydi; AC787/AC788 alohida test qilingan, birgalikda holat spec'da ham talab qilinmagan.

qa-ep-09-t06-s02 qabul mezonini belgiladi

✓ Hajm limiti va MIME allowlist konfiguratsiyadan o'qiladi (kodda qotirilmagan)

qa-ep-09-t06-s02 qabul mezonini belgiladi

✓ Kodda `upload_status` enum va tozalash cron'i YO'Q (kod tekshiruvi)

qa-ep-09-t06-s02 qabul mezonini belgiladi

✓ Muvaffaqiyatli yo'l: obyekt + DB qatori (`file_key`, `mime_type`, `size_bytes`) yaratiladi — AC42

qa-ep-09-t06-s02 qabul mezonini belgiladi

✓ Uzilgan yuklashdan keyin na obyekt, na DB qatori qoladi — E21/AC33

qa-ep-09-t06-s02 qabul mezonini belgiladi

✓ DB `COMMIT` majburan yiqitilganda qo'yilgan obyekt kompensatsiya bilan o'chiriladi — AC33

qa-ep-09-t06-s02 qabul mezonini belgiladi

✓ Kengaytmasi to'g'ri, lekin magic bytes mos kelmagan fayl `415` beradi va omborga yozilmaydi — AC32

qa-ep-09-t06-s02 qabul mezonini belgiladi

✓ Chegaradan katta fayl `413 FILE_TOO_LARGE` beradi va omborga HECH NARSA yozilmaydi — AC32

coder-ep-09-t06-s02 statusni o'zgartirdi Ishlanyapti → Review

coder-ep-09-t06-s02 yangiladi

Yangilandi: branch, commit_sha

coder-ep-09-t06-s02 izoh qoldirdi

Dizayn qarorlari: (1) FileUploadService.upload(domain, declaredContentType, InputStream, Function<StoredObject,T>) — 2-4-qadam tekshiruvi + 5-qadam yozish + 6-qadam callback/kompensatsiya SHU YERDA; 1-qadam (rule+egalik) va DB persist chaqiruvchida (parent AC782, callback orqali). (2) Extension original fayl nomidan EMAS, tasdiqlangan MIME turidan (KnownFileSignature) olinadi — R43c bilan izchil. (3) MIME allowlist tekshiruvi (3-qadam) R42 raqamlanishidan farqli, hajm tekshiruvidan (2-qadam) OLDIN bajariladi — ikkalasi ham obyekt yozuvidan oldin, faqat samaradorlik uchun (allaqachon rad etiladigan MIME uchun oqim o'qilmaydi); AC/xatti-harakatga ta'sir qilmaydi. (4) Allowlist'ga qo'shilgan MIME turi uchun KnownFileSignature'da signatura bo'lishi SHART — bo'lmasa fail-closed 415 (xavfsizlik, R42 4-qadam 'tekshirib bo'lmaydi' holatini yutib yubormaslik uchun). (5) Hajm/MIME sukut qiymatlari (10MB, PDF/JPEG/PNG) — muhandislik boshlang'ich taxmini (application.yml da izohlangan), spec ataylab qotirmagan (OPEN_QUESTIONS #11), env orqali o'zgaradi. ESLATMA: GlobalExceptionHandler.java'ga qo'shgan ikkita handler (FileTooLargeException/UnsupportedFileTypeException) parallel S03 bilan bir vaqtda umumiy fayl ustida ishlaganimiz sababli S03 commit'i (241828f) ichiga tushib ketdi (working tree umumiy edi) — funksional to'g'ri, testlangan (mvn test yashil), faqat git atributsiyasi S03 commit'ida.

coder-ep-09-t06-s02 qabul mezonini belgiladi

✓ Hajm limiti va MIME allowlist konfiguratsiyadan o'qiladi (kodda qotirilmagan)

coder-ep-09-t06-s02 qabul mezonini belgiladi

✓ Kodda `upload_status` enum va tozalash cron'i YO'Q (kod tekshiruvi)

coder-ep-09-t06-s02 qabul mezonini belgiladi

✓ Muvaffaqiyatli yo'l: obyekt + DB qatori (`file_key`, `mime_type`, `size_bytes`) yaratiladi — AC42

coder-ep-09-t06-s02 qabul mezonini belgiladi

✓ Uzilgan yuklashdan keyin na obyekt, na DB qatori qoladi — E21/AC33

coder-ep-09-t06-s02 qabul mezonini belgiladi

✓ DB `COMMIT` majburan yiqitilganda qo'yilgan obyekt kompensatsiya bilan o'chiriladi — AC33

coder-ep-09-t06-s02 qabul mezonini belgiladi

✓ Kengaytmasi to'g'ri, lekin magic bytes mos kelmagan fayl `415` beradi va omborga yozilmaydi — AC32

coder-ep-09-t06-s02 qabul mezonini belgiladi

✓ Chegaradan katta fayl `413 FILE_TOO_LARGE` beradi va omborga HECH NARSA yozilmaydi — AC32

coder-ep-09-t06-s02 fayllarni qayd etdi

12 ta fayl qayd etildi

coder-ep-09-t06-s02 statusni o'zgartirdi Backlog → Ishlanyapti

Agent ishni boshladi

coder-ep-09-t06-s02 ishga oldi

pm-agent bog'liqlik qo'shdi

→ EP-09-T06-S01

pm-agent yaratdi

Proxy upload — R42 ning 6 qadami va kompensatsiya