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

Kho · warehouse/update · api

PUT/api/client/page/warehouse/update

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

Báo cáo sai lệch — warehouse/update — vòng 1

…/ = src/main/java/com/softdreams/easypos/warehouse/ (repo đích C:/Projects/warehouse-service).

0. Kết luận nhanh

  • Điều kiện đạt: G1 ✅ G2 ✅ G3 ✅ G4 — G5 ✅ G6 ✅ → CHỜ KIỂM SONAR (máy đạt hết, chờ người kiểm G4)
  • Trạng thái: SẴN SÀNG CHO NGƯỜI XEM
  • Tầng rủi ro: A (tự động — R-03 phân quyền, R-13 khoá, R-14) → người cần đọc: spec + báo cáo + toàn bộ diff (diff nhỏ: 3 file main, 2 file i18n)
  • Số quy tắc: 14 · PASS 5 · DEVIATION có chủ đích 7 · DEVIATION KHÔNG chủ đích 0 · UNVERIFIED 2
  • Coverage thấp nhất: F-01 100% dòng / 100% nhánh
  • Finding logic: CRITICAL 0 · MAJOR 0 · MINOR 1 · UNSURE 0
  • Nghi vấn bug code cũ (mục 3c): 9 (CAO 0) · Quyết định tự chốt cần xác nhận (mục 3d): 8
  • Chạy bằng: /mig-auto (spec do spec-reviewer kiểm, chưa có người duyệt) · Số vòng: 1 verify / lần sửa 0/3
  • Phần lưu (saveWarehouse, Warehouse.update, kiểm trùng, adapter) tái sử dụng nguyên từ unit warehouse/create; unit này chỉ thêm endpoint PUT /update, mã lỗi ID_NOT_NULL và text i18n.

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

Mã Mục tiêu Kết quả Bằng chứng
G1 Kiến trúc ADR (mvnw verify: build, test, ArchUnit, Checkstyle/PMD/SpotBugs) ✅ verify/round-1/build.md (575 test, ArchUnit 36/36)
G2 Test khớp test-plan, mọi R-xx có test ✅ verify/round-1/oracle.md (37/37 TC khớp)
G3 Coverage mỗi luồng (dòng ≥ 80%, nhánh ≥ 70%) ✅ verify/round-1/coverage.md
G4 0 issue Sonar (người kiểm bằng SonarQube for IDE) CHỜ NGƯỜI sonar-ide.md (CHƯA KIỂM)
G5 0 finding logic CRITICAL/MAJOR đã xác nhận ✅ verify/round-1/review-logic.md, verification.md (không cần xác minh)
G6 Không lách cổng, không ghi ngoài phạm vi ✅ verify/round-1/gates.md; 8/8 file có trong impl-notes.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, GM-02 trong test-plan.md mục 3)

Coverage theo luồng

Luồng Tên % dòng % nhánh
F-01 Sửa kho 100% (6/6) 100% (2/2)

2. Ma trận truy vết

Quy tắc Tầng Code mới Test Golden Kết luận
R-01 Bắt buộc id trước validate B …/presentation/web/warehouse/WarehouseController.java:72-74 TC-01, TC-02, TC-03 — DEVIATION (có chủ đích, D-02 — chỉ định dạng body)
R-02 Validate B WarehouseController.java:75 TC-04, TC-05 — DEVIATION (có chủ đích, D-02)
R-03 Công ty theo token A …/application/warehouse/WarehouseManagementService.java:77 TC-06 — DEVIATION (có chủ đích, D-01)
R-04 Kho phải thuộc công ty B WarehouseManagementService.java:88-89 TC-07, TC-08 — PASS
R-05 Chép đè B …/domain/warehouse/model/Warehouse.java (update, copyFrom) TC-09 GM-01 PASS
R-06 SKU mặc định B Warehouse.java (copyFrom) TC-09, TC-10, TC-12 — PASS
R-07 Tên chuẩn hoá B Warehouse.java (copyFrom) TC-09, TC-11, TC-12 — PASS
R-08 Kiểm trùng (đếm 2) B WarehouseManagementService.java:113-121, …/domain/warehouse/policy/WarehouseDuplicatePolicy.java TC-13…TC-21 GM-02 UNVERIFIED (hành vi flush Hibernate cũ — LF-34; golden chưa chạy)
R-09 Luật WH1 B Warehouse.java (validateDefaultWarehouse) TC-22…TC-26 — DEVIATION (có chủ đích, D-03: 417 → 500)
R-10 Ngừng kho còn đơn B WarehouseManagementService.java:95-97,123-130 TC-27…TC-30 GM-01 PASS
R-11 Lưu, làm sạch, audit khi có thay đổi B Warehouse.java (update, cleanText), WarehouseRelationalRepository.save TC-31…TC-34 GM-02 UNVERIFIED (@PreUpdate chỉ khi dirty, UPDATE @DynamicUpdate — SQL thật chưa chạy, K-13)
R-12 Response thành công B WarehouseController.java:76-79 TC-35 — DEVIATION (có chủ đích, D-02: reason là mã)
R-13 Khoá theo công ty A WarehouseManagementService.java:78 TC-36 — DEVIATION (có chủ đích, D-05); khoá thật trên MSSQL UNVERIFIED (K-12, K-13)
R-14 Kiểm gói dịch vụ A (không có) TC-37 — DEVIATION (có chủ đích, D-12 — không chuyển)

3. Người cần xem

# Vị trí Vì sao cần người xem
1 Toàn bộ diff (verify/round-1/changes.diff) Tầng A — đọc hết; phần main chỉ khoảng 30 dòng
2 …/presentation/web/warehouse/WarehouseController.java:61-80 Endpoint mới: kiểm id phải đứng trước Guard.validateInput (D-13)
3 F-logic-1 (MINOR) — WarehouseRelationalRepository.java:125-134 Lỗi ràng buộc DB (ví dụ tên dài hơn cột) ở code cũ ném trước lỗi nghiệp vụ (do flush sớm), code mới ném sau → cùng input sai cả hai có thể ra mã lỗi khác (cũ 417 EXCEPTION_ERROR, mới 400 nghiệp vụ). Chưa có D-xx; reviewer đề xuất ghi nhận chứ không mô phỏng flush sớm. Người quyết có chấp nhận không
4 R-08, R-11 UNVERIFIED Dựa vào hành vi runtime Hibernate 5.6 của monolith (flush trước native query, @PreUpdate chỉ khi dirty) — cần golden master GM-02 hoặc SQL log để xác nhận
5 R-13 sp_getapplock chỉ kiểm bằng mock (K-12, K-13) — cần chạy thử trên MSSQL thật
6 G4 Sonar chưa kiểm — xem hướng dẫn cuối report

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 Sửa kho 10 KHỚP / 3 KHÁC (D-01, D-05 có chủ đích; thời điểm ghi DB — F-logic-1) / 1 CHỈ CÓ Ở CŨ (kiểm gói — D-12) / 0 Không Thứ tự kiểm id trước validate; businessValues thay dirty check; dòng của chính kho mang giá trị hiện tại trong kiểm trùng; tham số lỗi đơn là tên sau làm sạch; UPDATE chỉ lúc commit; sp_getapplock chưa chạy MSSQL thật

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

Đường dẫn code cũ: easyposbase:src/main/java/sds/ep/baseservice/services/impl/BaseWarehouseServiceImpl.java gọi tắt là BaseWarehouseServiceImpl.

B-01 Sửa kho mà không gửi đủ mọi trường thì trường thiếu bị xoá, và quên gửi "trạng thái" là kho bị ngừng hoạt động

  • Mức nghi ngờ: TRUNG BÌNH — chắc chắn code cũ làm vậy; không biết frontend có luôn gửi đủ form không.
  • Ở đâu: code cũ BaseWarehouseServiceImpl:182, easyposbase:…/dto/warehouse/WarehouseSaveRequest.java:75-77 → code mới (giữ nguyên) …/domain/warehouse/model/Warehouse.java (update, copyFrom), …/domain/warehouse/command/SaveWarehouseCommand.java (activeStatus)
  • Code cũ đang làm gì: khi sửa, hệ thống chép đè mọi trường gửi lên vào kho, kể cả trường để trống. Trường "đang hoạt động" để trống được hiểu là "ngừng hoạt động".
  • Ví dụ cụ thể: kho 5 "Kho A", mã SKU "K05", SĐT 0901, địa chỉ HN, đang hoạt động, cho bán. Gửi PUT /update {"id":5,"comId":10,"name":"Kho A1"} để đổi tên → hệ thống cũ (và mới) lưu: tên "Kho A1", SKU thành "WH5", SĐT/địa chỉ/mô tả bị xoá, "cho bán" thành trống, kho ngừng hoạt động. Nếu kho đang có đơn chưa xử lý thì lại báo lỗi "Kho Kho A1 có đơn hàng chưa xử lý…" dù người dùng chỉ muốn đổi tên. Nếu đúng nghiệp vụ thì trường không gửi lẽ ra giữ nguyên.
  • Vì sao nghi là sai: chỉ thiếu một trường mà mất dữ liệu và ngừng kho; khó đoán với client.
  • Ảnh hưởng nếu đúng là bug: client gọi API với body thiếu (app mobile, tích hợp) làm ngừng kho → không bán/xuất được. Nếu frontend luôn gửi đủ form thì không gặp.
  • Đã xử lý khi chuyển: GIỮ nguyên. Test khoá: TC-09 (WarehouseManagementServiceTest$UpdateEndpoint#overwritesAllFieldsAndDeactivates), TC-30 (#missingStatusWithBillsFails).
  • Nếu muốn sửa: trong Warehouse.update coi field null là giữ nguyên, status null là giữ nguyên; đổi TC-09, TC-30. Hành vi này dùng chung với /create có id (B-01 của warehouse/create) — nên đổi cả hai. Monolith còn chạy song song sẽ lệch.
  • Liên quan: D-06, R-05, R-10

B-02 Sửa kho mặc định WH1 mà không gửi "cho bán" thì báo lỗi hệ thống

  • Mức nghi ngờ: TRUNG BÌNH — rõ là lỗi lập trình (NullPointerException); với sửa kho thì dễ gặp hơn tạo mới vì công ty nào cũng có kho WH1.
  • Ở đâu: code cũ BaseWarehouseServiceImpl:219-227 → code mới (giữ nguyên) Warehouse.java (validateDefaultWarehouse)
  • Code cũ đang làm gì: kho WH1 phải luôn hoạt động và cho bán; khi kiểm "cho bán" mà trường này trống thì chương trình lỗi.
  • Ví dụ cụ thể: PUT /update {"id":1,"comId":10,"name":"Kho tổng","status":true} với kho 1 là WH1 → cũ: 417 "Lỗi hệ thống"; mới: 500 EXCEPTION_ERROR "Lỗi hệ thống"; không lưu. Lẽ ra báo lỗi rõ ràng hoặc giữ giá trị cũ.
  • Vì sao nghi là sai: lỗi hệ thống thay cho thông báo nghiệp vụ.
  • Ảnh hưởng nếu đúng là bug: client không gửi sellable không sửa được kho chính, chỉ thấy "Lỗi hệ thống".
  • Đã xử lý khi chuyển: GIỮ nguyên. Test khoá: TC-24 (WarehouseManagementServiceTest$UpdateEndpoint#defaultWarehouseWithoutSellableIsSystemError).
  • Nếu muốn sửa: Warehouse.validateDefaultWarehouse coi null như giữ giá trị cũ hoặc trả 400 UPDATE_WAREHOUSE_DEFAULT_INVALID; đổi TC-24 (và TC-31 của warehouse/create).
  • Liên quan: D-10, D-03, R-09

B-03 Kiểm trùng tên/mã kho phân biệt hoa thường, nên đổi tên thành "kho b" vẫn được dù đã có "Kho B"

  • Mức nghi ngờ: TRUNG BÌNH — code rõ ràng; không rõ nghiệp vụ có cố ý không.
  • Ở đâu: code cũ BaseWarehouseServiceImpl:195-205,230-232 → code mới (giữ nguyên) …/domain/warehouse/policy/WarehouseDuplicatePolicy.java
  • Code cũ đang làm gì: so tên/mã gửi lên nguyên văn với tên/mã đã lưu, giống hệt từng ký tự mới coi là trùng.
  • Ví dụ cụ thể: kho 5 "Kho A", kho 6 "Kho B". Sửa kho 5 thành "kho b" → lưu được → công ty có "kho b" và "Kho B".
  • Vì sao nghi là sai: luật "tên kho không trùng" bị lách bằng chữ hoa/thường.
  • Ảnh hưởng nếu đúng là bug: danh sách kho có tên gần như trùng, chọn nhầm kho.
  • Đã xử lý khi chuyển: GIỮ nguyên. Test khoá: TC-19 (WarehouseManagementServiceTest$UpdateEndpoint#nameComparisonIsCaseSensitive).
  • Nếu muốn sửa: WarehouseDuplicatePolicy.validate so không phân biệt hoa thường sau khi làm sạch; đổi TC-19 (và TC-24 của warehouse/create).
  • Liên quan: D-08, R-08

B-04 Đổi tên/mã kho thành tên/mã của kho khác kèm một dấu cách thừa thì lọt kiểm trùng

  • Mức nghi ngờ: TRUNG BÌNH — logic "đếm 2 mới báo trùng" đúng nhờ tác dụng phụ của ORM; hành vi runtime cũ chưa kiểm trên DB (UNVERIFIED).
  • Ở đâu: code cũ BaseWarehouseServiceImpl:175-205,235-245, easyposbase:…/repositories/BaseWarehouseRepository.java:37-38 → code mới (giữ nguyên) …/application/warehouse/WarehouseManagementService.java:113-121 (duplicateRows), WarehouseDuplicatePolicy.java
  • Code cũ đang làm gì: khi sửa, chỉ báo trùng nếu đếm được 2 dòng trùng (một là chính kho). Dòng của chính kho mang tên/mã mới đã bỏ dấu cách thừa, còn giá trị đem so vẫn còn dấu cách.
  • Ví dụ cụ thể: kho 5 "Kho A" (mã K05), kho 6 "Kho B" (mã K06). Sửa kho 5 thành "Kho B" → bị chặn (đúng). Sửa thành "Kho B " → lưu thành "Kho B" → hai kho "Kho B". Sửa mã kho 5 thành "K06 " → lưu "K06" → hai kho mã K06.
  • Vì sao nghi là sai: luật không trùng bị lách bằng một dấu cách.
  • Ảnh hưởng nếu đúng là bug: tên/mã trùng; sau đó còn khoá cứng việc sửa (B-05).
  • Đã xử lý khi chuyển: GIỮ nguyên. Test khoá: TC-14 (#trailingSpaceNameSlipsThrough), TC-18 (#trailingSpaceSkuSlipsThrough), TC-13 (#renamingToAnotherNameIsRejected).
  • Nếu muốn sửa: loại dòng của chính kho rồi trùng 1 là lỗi, so giá trị đã làm sạch; đổi TC-13, TC-14, TC-18.
  • Liên quan: D-09, R-08, R-11

B-05 Công ty đã có sẵn hai kho trùng tên/mã thì không sửa được thông tin gì của hai kho đó nếu giữ tên/mã

  • Mức nghi ngờ: TRUNG BÌNH — hệ quả trực tiếp của B-04 và kiểm trùng thiếu khoá (D-05); spec-reviewer phát hiện (F-spec-2).
  • Ở đâu: code cũ BaseWarehouseServiceImpl:190-205,235-245 → code mới (giữ nguyên) WarehouseDuplicatePolicy.java
  • Code cũ đang làm gì: đếm cả dòng của chính kho; công ty đã có hai kho cùng tên thì kho nào cũng đếm được 2.
  • Ví dụ cụ thể: kho 5 "Kho B", kho 6 "Kho B". Sửa SĐT kho 5 thành 0909 (giữ tên) → 400 "Tên kho hàng đã tồn tại"; không đổi được SĐT, không ngừng được kho, trừ khi đổi tên. Tương tự với hai kho cùng mã "K05".
  • Vì sao nghi là sai: dữ liệu trùng do chính lỗ hổng kiểm trùng sinh ra lại chặn việc sửa.
  • Ảnh hưởng nếu đúng là bug: người dùng bị kẹt, phải đổi tên kho mới sửa được.
  • Đã xử lý khi chuyển: GIỮ nguyên. Test khoá: TC-16 (#existingDuplicateNameBlocksUpdate), TC-17 (#existingDuplicateSkuBlocksUpdate).
  • Nếu muốn sửa: như B-04; đổi TC-16, TC-17.
  • Liên quan: D-14, R-08

B-06 Không gửi mã SKU thì SKU bị đặt lại bằng mã kho mà không kiểm trùng, và tìm kho theo mã không còn ra

  • Mức nghi ngờ: THẤP — ảnh hưởng nhỏ.
  • Ở đâu: code cũ BaseWarehouseServiceImpl:183-189 → code mới (giữ nguyên) Warehouse.java (copyFrom)
  • Code cũ đang làm gì: SKU trống → lấy mã kho; nhưng tên chuẩn hoá (dùng để tìm kiếm) tính từ SKU gửi lên (trống), và SKU mặc định không được kiểm trùng. SKU chỉ toàn dấu cách bị lưu thành rỗng.
  • Ví dụ cụ thể: kho 5 (mã WH5, SKU K05, tên chuẩn hoá "khoa|k05"). Sửa không gửi SKU → SKU "WH5", tên chuẩn hoá "khoa" (mất phần mã). Nếu kho 6 đã có SKU "WH5" → vẫn lưu, hai kho SKU "WH5". Gửi SKU " " → SKU rỗng.
  • Vì sao nghi là sai: dữ liệu tìm kiếm không nhất quán; SKU trùng/rỗng.
  • Ảnh hưởng nếu đúng là bug: tìm kho theo mã có thể không ra; hiếm.
  • Đã xử lý khi chuyển: GIỮ nguyên. Test khoá: TC-10 (#blankSkuIsSavedEmpty), TC-12 (#missingSkuDefaultsToCode), TC-20 (#defaultSkuIsNotCheckedForDuplicate).
  • Nếu muốn sửa: trim SKU trước khi xét mặc định, tính tên chuẩn hoá từ SKU cuối, kiểm trùng SKU cuối; đổi TC-10, TC-12, TC-20.
  • Liên quan: D-07, R-06, R-07

B-07 Đổi tên kho thành toàn dấu cách vẫn lưu được, kho không có tên

  • Mức nghi ngờ: THẤP.
  • Ở đâu: code cũ easyposbase:…/dto/warehouse/WarehouseSaveRequest.java:14-15 (@NotEmpty) → code mới (giữ nguyên) …/presentation/web/warehouse/dto/request/WarehouseSaveRequest.java
  • Code cũ đang làm gì: chỉ chặn tên rỗng hẳn; tên " " qua được và bị làm sạch thành rỗng.
  • Ví dụ cụ thể: PUT /update {"id":5,"comId":10,"name":" ","sku":"K05","status":true} → 200, kho 5 tên rỗng.
  • Vì sao nghi là sai: kho không có tên hiển thị.
  • Ảnh hưởng nếu đúng là bug: danh sách kho có dòng trống tên; hiếm.
  • Đã xử lý khi chuyển: GIỮ nguyên. Test khoá: TC-05 (WarehouseControllerTest$UpdateEndpoint#blankNamePassesValidation).
  • Nếu muốn sửa: @NotBlank trên name (đổi cả /create); đổi TC-05.
  • Liên quan: D-11, R-02

B-08 Sửa kho không tồn tại trả lỗi máy chủ (500) thay vì "không tìm thấy"

  • Mức nghi ngờ: THẤP — có thể cố ý.
  • Ở đâu: code cũ BaseWarehouseServiceImpl:175-177 → code mới (giữ nguyên) WarehouseManagementService.java:88-89
  • Code cũ đang làm gì: id không thuộc công ty → lỗi kiểu máy chủ (HTTP 500) "Kho hàng không tồn tại".
  • Ví dụ cụ thể: PUT /update {"id":999,"comId":10,"name":"Kho A"} → 500. Lẽ ra 404/400.
  • Vì sao nghi là sai: lỗi do dữ liệu người gửi; giám sát tính nhầm là sự cố. Với PUT /update dễ gặp khi kho vừa bị xoá ở tab khác.
  • Ảnh hưởng nếu đúng là bug: cảnh báo giả; client hiển thị "lỗi hệ thống".
  • Đã xử lý khi chuyển: GIỮ nguyên. Test khoá: TC-07 (#missingWarehouseIsSystemError).
  • Nếu muốn sửa: NotFoundException; đổi TC-07 (và TC-43 của warehouse/create).
  • Liên quan: D-04, R-04

B-09 Thiếu id chỉ báo một lỗi, không gộp với các lỗi nhập liệu khác

  • Mức nghi ngờ: THẤP — ảnh hưởng rất nhỏ.
  • Ở đâu: code cũ easyposbackend1:…/web/rest/WarehouseResource.java:61-64 → code mới (giữ nguyên) WarehouseController.java:72-75
  • Code cũ đang làm gì: kiểm id trước, thiếu là trả lỗi ngay, chưa kiểm các trường khác.
  • Ví dụ cụ thể: PUT /update {"name":""} → chỉ "Id không được bỏ trống"; thêm id gửi lại mới thấy "Id công ty không được bỏ trống" và "Tên kho hàng trống".
  • Vì sao nghi là sai: khác cách validate trả đủ lỗi một lần.
  • Ảnh hưởng nếu đúng là bug: người dùng phải gửi lại nhiều lần; form sửa luôn có id nên hầu như không gặp.
  • Đã xử lý khi chuyển: GIỮ nguyên. Test khoá: TC-01 (WarehouseControllerTest$UpdateEndpoint#missingIdReportsOnlyIdNotNull).
  • Nếu muốn sửa: đưa id vào nhóm validate của update; đổi TC-01.
  • Liên quan: D-13, R-01

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 D-01 (LỖI KỸ THUẬT) Kiểm comId = công ty trong token (CurrentCompanyService, có sẵn trong saveWarehouse) user công ty 10 gửi {"id":7,"comId":20,…} → cũ 200 sửa kho công ty 20 / mới 400 COMPANY_NOT_OF_CURRENT_USER Đồng ý chặn sửa chéo công ty
2 D-02 (ADR BẮT KHÁC) Body response/lỗi theo starter thiếu id → cũ reason="Id không được bỏ trống" / mới reason="ID_NOT_NULL" (mã + HTTP 400 giữ nguyên); thành công reason="SUCCESS_UPDATE"; JSON hỏng → cũ 400 body rỗng / mới 400 INVALID_REQUEST Frontend đọc message[0].code/message[0].message chứ không đọc reason
3 D-03 (ADR BẮT KHÁC) SystemException(EXCEPTION_ERROR) WH1 không gửi sellable → cũ 417 / mới 500, cùng mã EXCEPTION_ERROR Frontend không phân biệt 417
4 D-05 (LỖI KỸ THUẬT) Khoá sp_getapplock theo công ty (có sẵn) hai request đồng thời đổi hai kho cùng thành "Kho C" → cũ: RCSI cả hai 200 (trùng tên) hoặc khoá dòng: deadlock, một 417 / mới: lần lượt, request sau 400 trùng tên. Không bảo vệ giữa monolith và service Đồng ý; chạy thử khoá trên MSSQL thật
5 D-12 (PHỤ THUỘC NGOÀI) Không chuyển kiểm gói dịch vụ gói hết hạn → cũ 400 ACCOUNT_EXPIRED / mới 200 sửa được Quyết tầng nào kiểm gói (gateway, starter, interceptor chung) — chung với warehouse/create D-16
6 spec-review Spec qua 1 lần review (5 MINOR, đã CHẤP NHẬN cả 5; không có MAJOR/CRITICAL nên không gọi lần 2). Các quy tắc được sửa theo review: R-02, R-12 (trích dẫn), R-08 (edge case 6–8, D-14 mới), R-10 (tên mới trong thông báo), D-05 (ví dụ deadlock) — Đọc kỹ R-08, R-10 và D-14
7 F-logic-1 (MINOR, chưa có D-xx) Không sửa (đúng đề xuất reviewer: không mô phỏng flush sớm) tên dài hơn cột + kho WH1 ngừng → cũ 417 EXCEPTION_ERROR (lỗi DB lúc flush) / mới 400 UPDATE_WAREHOUSE_DEFAULT_INVALID Chấp nhận khác thứ tự lỗi ràng buộc DB; nếu đồng ý nên ghi thành D-xx LỖI KỸ THUẬT khi duyệt spec
8 Tái sử dụng warehouse/create Không đổi logic saveWarehouse của unit warehouse/create (đang CHỜ KIỂM SONAR, spec chưa có người duyệt) — Nếu người đổi D-xx nhánh sửa ở warehouse/create (D-04, D-09…D-13, D-15) thì unit này đổi theo

4. Finding đã xác nhận

Không có finding CRITICAL/MAJOR. Finding MINOR (không qua xác minh, chuyển cho người):

F-logic-1

  • Mức độ: MINOR
  • Loại: parity
  • Quy tắc: R-08, R-09, R-10, R-11
  • Code mới: …/application/warehouse/WarehouseManagementService.java:93-98; …/infrastructure/relational/warehouse/adapter/WarehouseRelationalRepository.java:129-133
  • Code cũ: easyposbase:src/main/java/sds/ep/baseservice/services/impl/BaseWarehouseServiceImpl.java:182-190
  • Mô tả: code cũ ghi UPDATE sớm ở lần flush trước câu kiểm trùng (LF-34), nên lỗi ràng buộc DB ném trước mọi kiểm nghiệp vụ; code mới UPDATE lúc commit, sau kiểm trùng, WH1 và kiểm đơn → input sai cả hai thì mã lỗi khác. Chưa có D-xx.
  • Kịch bản tái hiện: kho 1 WH1, {"id":1,"comId":10,"name":"<quá dài>","status":false,"sellable":true} → cũ 417 EXCEPTION_ERROR, mới 400 UPDATE_WAREHOUSE_DEFAULT_INVALID.
  • Đề xuất sửa: không mô phỏng flush sớm; ghi D-xx hoặc spec mục 7.
  • Độ tin cậy: trung bình (độ dài cột chưa xác minh — không có schema trong repo).
  • Xác minh: không qua xác minh (MINOR). Xử lý: đưa vào mục 3 và 3d #7.

5. Finding bị loại

Finding Lý do loại
(không có)

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

Không có vấn đề nào đang làm trượt cổng máy. Chỉ còn G4:

Vấn đề Cổng Chỉ thị
Sonar chưa kiểm (sonar-ide.md: CHƯA KIỂM) G4

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

Vấn đề Vòng trước Vòng này
(vòng đầu) — F-logic-1 MỚI (MINOR)

8. Thay đổi trong repo đích

8 file, tất cả trong src/main, src/test (chi tiết verify/round-1/changed-files.md), không có file ngoài phạm vi:

  • Main: WarehouseController.java (+24/−2: endpoint PUT /update), WarehouseErrorCode.java (+1: ID_NOT_NULL), WarehouseManagementService.java (chỉ Javadoc), i18n/messages_vi.properties, i18n/messages_en.properties (+1 mỗi file).
  • Test: WarehouseControllerTest.java (+128), WarehouseManagementServiceTest.java (+522), WarehouseDuplicatePolicyTest.java (+14) — test mới nằm trong lớp lồng UpdateEndpoint, tên [update] TC-xx.

9. Đề xuất bổ sung kinh nghiệm (/mig-learn gom vào proposal để người duyệt)

Đề xuất Đưa vào đâu (lessons.md / review-criteria.md / rule ArchUnit / CLAUDE.md)
API "update" dùng chung save() với "create" đã chuyển: chỉ cần thêm endpoint + kiểm riêng của controller; spec vẫn đặc tả lại đủ R-xx nhánh sửa có trích dẫn trực tiếp (để test/review độc lập), dùng lại spec F-02 của unit create để lần nhanh lessons.md Phần 2 (T-xx)
Flush sớm (K-01/LF-34) còn có hệ quả: lỗi ràng buộc DB của code cũ ném trước lỗi nghiệp vụ; code mới ghi lúc commit thì ngược lại — ghi sẵn D-xx ở bước spec (F-logic-1) lessons.md K-01 / legacy-facts.md LF-34
Kiểm trùng "đếm 2 mới lỗi" (LF-50): luôn xét trường hợp dữ liệu đã trùng sẵn (khoá cứng việc sửa) và cả cột SKU khi có lỗ hổng dấu cách (F-spec-2, F-spec-3) legacy-facts.md LF-50
Nhánh sửa + khoá dòng sau flush: hai request sửa hai kho khác nhau có thể deadlock ở câu SELECT toàn công ty (F-spec-5) — ghi vào ví dụ D-xx khoá lessons.md Phần 1a
Thêm test cho unit mới vào lớp test đã có test của unit khác: dùng @Nested + tiền tố [unit] TC-xx để không trùng mã TC lessons.md Phần 1c
warehouse/create decisions.md D-13 ví dụ ghi "mới: 500 NULL_EXCEPTION" nhưng spec R-10 và code dùng EXCEPTION_ERROR — ví dụ lệch, nên sửa khi người duyệt unit đó (ghi chú cho người, không phải bài học)

Nguồn của trang này

  • Báo cáo sai lệch migrations/warehouse/update/report.md vòng 1 · sha256 031766442601

v1 dựng 2026-11-06 00:42 · base commit đích b815e62356