EMS

背景¶

本票是 #1518 的子票，來源為 2026-09-28 對 MeterValues 第二～第五階段實作的 Astra 程式審查。該實作目前只存在主要 workspace，尚未部署至 A17；A17 已套用的第一階段複合索引不受本票影響。

工作位置：

• EMS workspace：/Users/ken/Documents/workspace/workspace_cloudlink/ems
• EMS branch：feature/redmine-1517-ocpp-liveness
• java/charge_point 為獨立 repository，使用相同 branch 名稱
• 直接使用主要 workspace，不建立 worktree
• 未經 Ken 指示不得部署或重啟案場服務

問題¶

MeterValues 背景 dispatcher 與 StopTransaction、StatusNotification、StartTransaction 等 Connector 狀態事件使用不同發布路徑，沒有共用同一個 per-connector 順序或 authoritative state version。

可能順序：

1. MeterValues 背景工作先讀到 Connector 仍為充電中。
2. StopTransaction 提交，Branch 先發布已停止快照。
3. 前面的 MeterValues 工作較晚完成，卻發布先前讀到的充電中快照。
4. HQ／Admin／LIFF 直接合併後到的資料，畫面可能回退為充電中。

目前 event timestamp 是發布當下時間，舊狀態晚送時反而會取得較新的 timestamp，因此接收端無法用現有時間欄位辨識。

影響¶

• 使用者已停止充電後，畫面可能再次顯示充電中。
• currentTransactionId、driverState、可用操作或即時數值可能被舊快照帶回。
• 若前一交易的背景工作晚到，也可能干擾下一筆交易畫面。

相關程式¶

• java/ems_branch/.../MeterValueConnectorEventDispatcher.java
• java/ems_branch/.../TransactionService.java
• java/ems_branch/.../StatusNotificationHandler.java
• java/ems_branch/.../ConnectorEventPublisher.java
• java/ems_hq/.../ConnectorEventSubscriber.java
• react/web/app/charger/store/useChargingStore.ts

建議修正¶

• MeterValues、Start／StopTransaction、StatusNotification 等 commit-after 更新共用同一套 per-connector 發布序列。
• 背景工作只傳遞 ID／變更通知，輪到發布時重新讀取 authoritative state。
• 發布期間若收到新變更，完成本次後必須再重新載入及發布，確保最終狀態正確。
• 增加單調遞增的 state version；HQ、Admin 與 LIFF 必須忽略版本較舊的事件。
• 不得把 Connector event 再移回 OCPP CALLRESULT 的同步路徑。

驗收條件¶

1. 用 barrier／latch 讓 MeterValues 工作停在已讀取舊狀態、尚未發布，再完成 StopTransaction；放行後最終畫面仍為已停止。
2. StartTransaction、StopTransaction、StatusNotification 與 MeterValues 同 Connector 交錯時，最終快照一律與資料庫 authoritative state 相同。
3. 舊事件不能覆蓋較新的 currentTransactionId、driverState 或可用操作。
4. 不同 Connector 可並行處理，同一 Connector 必須保序。
5. OCPP MeterValues CALLRESULT 快速路徑不可因此重新被背景 snapshot 阻塞。

證據狀態¶

本項由完整發布路徑與併發順序分析確認，尚未執行 RabbitMQ／現場 E2E；修正時必須補正式可控制時序的 regression test。