Why does reconnect recount an FR5 completion already in our history?

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.

Is the second completion written as another durable event, or is only the displayed total wrong? I would not assume the same correction covers both.

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.

Can the operator see that it is the same attempt?

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.

Did closing and reopening the monitor restore the correct total?

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.

And replay that newly recovered completion twice. Fixing the old attempt case should not depend on an event having existed before the outage.

Please make the operator message plain. 'Recovered completion' beats an unexplained number changing.

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.

Thank you. Was that the installed monitor or a separate test screen?

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.

That is a useful repair account. The repeated receipt remains explainable, and the person on shift no longer has to subtract imaginary brackets.