Báo cáo chuyển đổi warehouse-service

batch · batch/delete-multiple · api

POST/api/client/page/batches/delete-multiple

Vòng
1
Cổng G1–G6
PENDING_SONAR
Bước
sonar-check
Nhánh đích
feat/thongpd/migrate-batch2

Báo cáo sai lệch — batch/delete-multiple — vòng 1

0. Kết luận nhanh

  • Điều kiện đạt: G1 ✅ G2 ✅ G3 ✅ G4 — G5 ✅ G6 ✅ → CHỜ KIỂM SONAR
  • Trạng thái: SẴN SÀNG CHO NGƯỜI XEM
  • Tầng rủi ro: B → người cần đọc: spec + báo cáo + đoạn bị gắn cờ
  • Số quy tắc: 7 · PASS 3 · DEVIATION có chủ đích 3 (R-01/R-06 D-02, R-02 D-07, R-07 D-03/D-04) · DEVIATION KHÔNG chủ đích 0 · UNVERIFIED 1 (R-02/R-07 nguồn đọc D-08)
  • Coverage thấp nhất: F-01 95.7% dòng / 100% nhánh
  • Finding logic: 0
  • Nghi vấn bug code cũ (mục 3c): 3 (CAO 1) · Quyết định tự chốt cần xác nhận (mục 3d): 6
  • Chạy bằng: /mig-auto · Số vòng: 1 / lần sửa 0/3

1. Điều kiện đạt

Mã Mục tiêu Kết quả Bằng chứng
G1 mvnw verify ✅ verify/round-1/build.md (646 test)
G2 Test khớp test-plan ✅ verify/round-1/tc-map.md (15/15), oracle.md
G3 Coverage ✅ verify/round-1/coverage.md
G4 Sonar CHỜ NGƯỜI sonar-ide.md
G5 Finding CRITICAL/MAJOR ✅ verify/round-1/review-logic.md (0)
G6 Lách cổng ✅ verify/round-1/gates.md

Không chặn nhưng cần người: Integration test CHƯA CHẠY · Golden master CHƯA CHẠY (GM-01; reviewer đề nghị thêm case ids chứa null)

Coverage theo luồng

Luồng Tên % dòng % nhánh
F-01 Xoá nhiều lô theo danh sách 95.7% (22/23) 100% (8/8)
F-02 Xoá mọi lô khớp bộ lọc 98.2% (54/55) 100% (30/30)

2. Ma trận truy vết

Quy tắc Tầng Code mới Test Golden Kết luận
R-01 B controller, request, mapper TC-01, 02 — DEVIATION có chủ đích (D-02)
R-02 B service, BatchFilterReader, BatchKeyword TC-03..08 GM-01 DEVIATION có chủ đích (D-07 chỉ lấy id); UNVERIFIED nguồn đọc (D-08), SQL mock
R-03 B service TC-09 — PASS
R-04 B BatchWriter.deleteAllWithoutDetails TC-10, 11 GM-01 PASS (giữ D-01, D-05, D-06)
R-05 B service TC-12 — PASS
R-06 B controller TC-13 — PASS
R-07 B translate, @Transactional TC-14, 15 — DEVIATION có chủ đích (D-03, D-04)

3. Người cần xem

# Vị trí Vì sao cần người xem
1 BatchManagementService.java:113-116, BatchWriter Xoá không lọc com_id; chọn tất cả theo comId body (B-01 CAO)
2 infrastructure/relational/batch/adapter/BatchFilterReader.java:22-63 SQL lọc nguyên văn bằng text block, chỉ test mock
3 D-08 Nguồn đọc DB chính / replica — cần chạy thật
4 ids chứa null Hibernate 6 bind [null] chưa rõ; có thể ra mã lỗi khác EXCEPTION_ERROR (reviewer, không thành finding)
5 G4 Chưa kiểm Sonar

3b. Phân tích luồng sau chuyển

Chi tiết: verify/round-1/flow-analysis.md

Luồng Tên Số bước KHỚP / KHÁC / CHỈ CÓ Ở CŨ / CHỈ CÓ Ở MỚI Lệch luồng đã duyệt (spec mục 6) Điểm dev cần chú ý
F-01 Xoá nhiều lô theo danh sách 10 bước: KHỚP 6 / KHÁC có chủ đích 4 (D-02 ở 2 bước, D-03, D-04) / CHỈ CÓ Ở CŨ 0 / CHỈ CÓ Ở MỚI 0 không Rollback cả lượt dựa vào BadRequestException ném trong @Transactional (BatchManagementService.java:113-116). Câu xoá một IN không lọc com_id (D-01, D-06). ids chứa null chưa chạy thật.
F-02 Xoá mọi lô khớp bộ lọc 13 bước: KHỚP 9 / KHÁC có chủ đích 4 (D-07, D-08, D-03, D-02) / CHỈ CÓ Ở CŨ 0 / CHỈ CÓ Ở MỚI 0 không SQL lọc ghép bằng text block (BatchFilterReader.java:22-63), mới khoá bằng mock. comId null bind "". comId lấy từ body (D-01, mức CAO). Đọc DB chính trong transaction ghi (D-08).

3c. Nghi vấn bug / sai ở code cũ (đã GIỮ nguyên khi chuyển)

B-01 Xoá được lô của công ty khác; "chọn tất cả" theo comId client gửi

  • Mức nghi ngờ: CAO
  • Ở đâu: code cũ backend:service/impl/BatchesManagementServiceImpl.java:359-386, backend:repository/impl/BatchRepositoryImpl.java:350-364 → code mới BatchManagementService.deleteMultiple, BatchWriter, BatchFilterReader
  • Code cũ đang làm gì: không đọc công ty của người gọi; xoá theo danh sách id bất kỳ; "chọn tất cả" dùng comId trong body.
  • Ví dụ cụ thể: nhân viên công ty 10 gửi {"comId":20,"paramCheckAll":true} → mọi lô chưa có tồn của công ty 20 bị xoá (nếu công ty 20 không có lô nào đã có tồn). Gửi {"ids":[5,7]} với lô của công ty 20 → xoá được.
  • Vì sao nghi là sai: lộ quyền ghi giữa các khách hàng.
  • Ảnh hưởng nếu đúng là bug: mất dữ liệu lô của khách hàng khác.
  • Đã xử lý khi chuyển: GIỮ. Test khoá: TC-03 (BatchManagementServiceTest$DeleteMultiple#checkAllUsesFilter), TC-10 (BatchRelationalRepositoryTest$DeleteAllSql#deleteAllSql).
  • Nếu muốn sửa: kiểm comId body = công ty token (như CurrentCompanyService), thêm AND b.com_id = :comId vào câu xoá; đổi TC-03, TC-10.
  • Liên quan: D-01, R-02, R-04

B-02 Một lô không xoá được làm hỏng cả lượt

  • Mức nghi ngờ: THẤP
  • Ở đâu: backend:service/impl/BatchesManagementServiceImpl.java:381-384 → BatchManagementService.deleteMultiple
  • Code cũ đang làm gì: số dòng xoá khác số id → báo lỗi và hoàn tác hết.
  • Ví dụ cụ thể: chọn 50 lô, 1 lô đã có tồn → không xoá lô nào, báo "Số lô đã phát sinh giao dịch"; gửi trùng [5,5] → lỗi.
  • Vì sao nghi là sai: không cho biết lô nào lỗi; trùng id cũng lỗi.
  • Ảnh hưởng nếu đúng là bug: người dùng phải tự dò lô có tồn.
  • Đã xử lý khi chuyển: GIỮ. Test khoá: TC-11, TC-12.
  • Nếu muốn sửa: bỏ trùng id, trả danh sách lô không xoá được; đổi TC-11, TC-12.
  • Liên quan: D-05, R-05

B-03 Chọn quá nhiều lô (> ~2100) thì lỗi hệ thống

  • Mức nghi ngờ: THẤP
  • Ở đâu: backend:repository/impl/BatchRepositoryImpl.java:355-362 → BatchWriter.deleteAllWithoutDetails
  • Code cũ đang làm gì: một câu IN cho mọi id; SQL Server giới hạn 2100 tham số.
  • Ví dụ cụ thể: công ty 3000 lô, "chọn tất cả" → lỗi hệ thống.
  • Vì sao nghi là sai: chức năng chọn tất cả không dùng được với công ty lớn.
  • Ảnh hưởng nếu đúng là bug: công ty nhiều lô.
  • Đã xử lý khi chuyển: GIỮ. Test khoá: TC-10 (một câu duy nhất).
  • Nếu muốn sửa: chia lô ≤ 2000 trong một transaction; đổi TC-10.
  • Liên quan: D-06, R-04

3d. Quyết định AI tự chốt và thay đổi tự động (cần người xác nhận)

# Nguồn AI đã làm gì Khác code cũ ở điểm nào (input → cũ / mới) Người cần xác nhận gì
1 spec-review F-spec-1 (MAJOR) — CHƯA QUYẾT Giữ cách hiểu đọc DB chính (đồng bộ batch/get-with-paging D-10), R-07 UNVERIFIED, thêm D-08 Reviewer cho rằng cũ đọc replica ngoài transaction Chạy thử: field @Autowired + @PersistenceContext(readOnlyPersistenceUnit) của BatchRepositoryImpl nhận EM nào
2 spec-review Spec qua 1 lần review (tầng B, không CRITICAL); đã sửa theo MAJOR: R-07, D-08 — Đọc R-02, R-07
3 D-07 (LỖI KỸ THUẬT) Chọn tất cả chỉ SELECT b.id lỗi map/đếm của câu cũ → cũ 417 / mới không lỗi; tập id như nhau Chấp nhận
4 D-02 (ADR BẮT KHÁC) Body theo starter {"ids":"x"} → cũ 400 rỗng / mới 400 starter Chấp nhận
5 D-03 (ADR BẮT KHÁC) 417 → 500 giữ mã 3000 ids → cũ 417 / mới 500 Chấp nhận
6 D-04 (PHỤ THUỘC NGOÀI) Không kiểm gói hết hạn dùng thử → cũ 400 / mới xoá Gói kiểm ở đâu

4. Finding đã xác nhận

Không có.

5. Finding bị loại

Không có.

6. Xử lý của người

Vấn đề Cổng Chỉ thị
Chưa kiểm Sonar G4

7. So với vòng trước

Vòng đầu.

8. Thay đổi trong repo đích

15 file: mới BatchDeleteMultipleRequest, BatchDeleteMultipleCommand, BatchFilter, BatchKeyword, BatchFilterReader, BatchFilterReaderTest; sửa BatchController, BatchWebMapper, BatchManagementService, BatchRepository, BatchRelationalRepository, BatchWriter và 3 file test (file của unit trước cùng lượt — thêm code). Không có file ngoài phạm vi.

9. Đề xuất bổ sung kinh nghiệm

Đề xuất Đưa vào đâu
BatchRepositoryImpl.entityManager có cả @Autowired và @PersistenceContext(readOnlyPersistenceUnit): hai reviewer/unit suy luận ngược nhau (EM chính / replica) — cần chạy thử một lần rồi ghi thành LF để các unit sau không tranh luận lại legacy-facts.md (LF mới), K-24
Common.setParams (backend) và BaseCommon.setParams (model) đều bind null thành ""; riêng setParamsWithPageable bind thẳng null — cột int so '' thành so 0 legacy-facts.md

Nguồn của trang này

  • Báo cáo sai lệch migrations/batch/delete-multiple/report.md vòng 1 · sha256 60782b82e0a9

v1 dựng 2026-11-09 14:46 · base commit đích 661efe9b8c