Phân tích luồng sau chuyển — batch/job-daily-update-status — vòng 1

logic-reviewer viết dựa trên code đã implement (không phải thiết kế trong spec), đối chiếu với code cũ. Dev đọc file này cùng changes.diff: mỗi luồng cho biết code mới đi qua những đâu, khác code cũ ở bước nào, và chỗ nào cần đọc kỹ.

Viết tắt: BMS = easyposbackend1:src/main/java/vn/softdreams/easypos/service/impl/BatchesManagementServiceImpl.java; SCH = presentation/scheduler/BatchStatusUpdateScheduler.java; SVC = application/batch/BatchStatusUpdateService.java; REPO = infrastructure/relational/batch/adapter/BatchRelationalRepository.java; WR = infrastructure/relational/batch/adapter/BatchStatusWriter.java; EW = domain/batch/model/BatchExpiryWarning.java; SP = domain/batch/model/BatchStatusPolicy.java (đường dẫn dưới src/main/java/com/softdreams/easypos/warehouse/).

F-01 Cập nhật trạng thái hạn dùng của lô

• Điểm vào: cũ BMS:113-128 → mới SCH:44-57 (updateStatusesOfBatches)
• Quy tắc: R-01, R-02, R-03, R-04, R-05, R-06

Sơ đồ luồng mới (theo code thực tế)

sequenceDiagram
    participant SCH as BatchStatusUpdateScheduler.updateStatusesOfBatches
    participant L as DistributedLockManager.acquireLock
    participant S as BatchStatusUpdateService.updateStatuses (@Transactional)
    participant R as BatchRelationalRepository
    participant W as BatchStatusWriter
    Note over SCH: cờ app.scheduler.enabled + app.scheduler.batch-status-update.enabled; cron 0 25 0/4 * * ?
    SCH->>SCH: try { clientId = BatchExpiryWarningScheduler.clientId()
    SCH->>L: acquireLock(job-lock-daily-update-status, clientId, 10m)
    L-->>SCH: false → LOG.info(LOCK_KEY), return
    SCH->>S: updateStatuses() [proxy, mở transaction]
    S->>R: findBatchesWithExpiryDate()
    R->>W: findWithExpiryDate(): JPQL SELECT b ... WHERE expDate IS NOT NULL (entity managed) → BatchStatusCandidate
    S->>S: today = LocalDate.ofInstant(clock.instant(), systemDefault).atStartOfDay
    loop mỗi lô
      S->>S: BatchExpiryWarning(unit, value) + BatchStatusPolicy.statusOf (NPE nếu unit null / value null với unit 1-3)
      S->>S: status khác batch.status() → thêm BatchStatusChange
    end
    S->>S: changes rỗng → return (commit rỗng)
    S->>R: updateStatuses(changes, ZonedDateTime.ofInstant(clock.instant()))
    R->>W: find (cache cấp 1) → setStatus, updater=0, updateTime, LegacyCleanText.clean(code/lotNo/normalizedName)
    S-->>SCH: commit → Hibernate UPDATE dynamic dòng dirty
    SCH->>SCH: catch RuntimeException → LOG.error (sau rollback)

Đối chiếu từng bước

Dữ liệu và side effect

Transaction, khoá, idempotency, tenant

• Ranh giới transaction: cũ @Transactional cấp class bao cả khoá và cập nhật → mới chỉ SVC.updateStatuses (SVC:40), gọi qua proxy từ SCH:52; khoá ngoài (D-09). Catch ở SCH ngoài transaction → rollback vẫn xảy ra (K-03).
• Khoá / cập nhật nguyên tử: không khoá dòng, không @Version ở cả hai bên; ghi đè status theo dữ liệu nạp đầu transaction (F-logic-2, nghi-bug-cu, cũ = mới).
• Idempotency, thời điểm phát event: không có event. Chạy lại (sau 10 phút hoặc node khác) → status đã đúng, không ghi thêm.
• Lọc comId: không lọc ở cả hai (job hệ thống, mọi công ty — R-03, D-05). Không có cache.
• Truy vấn: một SELECT; find trong WR:46 lấy từ persistence context, không N+1. Đọc DB chính (transaction không readOnly, K-24).

Lệch so với luồng mới đã duyệt (spec mục 6)

không

Dev cần chú ý khi review