Our durable history already contains the sample bracket's completed attempt. Nevertheless, the FR5 inspection monitor adds another completion when it reconnects and sees the PLC's retained completion high. I have kept the retained state and both monitor entries for the programmer. The remaining question is where the reconnect path stops consulting the history it successfully uses during normal operation.
Does reconnect rebuild a temporary list of seen attempts? An empty list at that point would fit what you describe, although the programmer needs to check the actual path.
It does rebuild that list. The normal event handler consults durable history, but the reconnect handler starts with an empty local set and increments before adding the attempt to it.
Two handlers deciding whether work is new sounds like the thing to remove. Let reconnect present the retained result to the same reconciliation path as a normal arrival.
Julia, a second receipt entry is saved, but it refers to the same completed attempt. The inflated count is in the monitor. Priya, the detailed view shows the identity; the large total does not explain its increase.
I would keep receipt entries, even repeated ones. They can explain a reconnect incident. The display total should be derived from completed attempts, not how often their information reached the monitor.
Blake, agreed about keeping the receipts. I would also make the repeated receipt visible as such, so somebody reading the detailed log does not think two bracket inspections occurred.
Chloe, a full reopen did restore it because that path loaded the completed attempts. The programmer has now routed reconnect through the same reconciliation used on normal arrival. Our retained-completion replay leaves the total unchanged.
What happens when an attempt completes during the outage and is therefore absent from that history when the connection drops? That must still appear once after reconnect.
The outage-completion case now adds one completed attempt. A repeated receipt adds no further count. We also tested an unresolved attempt with no result: it stays unresolved and creates no new submission.
Priya's message suggestion helps, but I would avoid making every ordinary receipt a notification. Show the recovery when it matters, and leave the detailed receipt trail available for investigation.
Chloe, we repeated those cases in the installed monitor with the application owner. The count remained correct through reconnect and reopening. Blake and Priya, recovered completions have an explanatory entry; repeated receipts stay in detail without another completion notice.