简体中文界面。帖子、指南及政策正文保留原文;未对原文作自动翻译。

our fr10 reconnect counts the completion it already saved

AnikaBennett0769 · 2026年3月4日 22:50 UTC

回复讨论
AN
AnikaBennett0769
Monitor reconnect sees a retained housing completion and increments the total again, although that attempt is already saved; how should the developer reconcile it without clearing evidence or resending the inspection?

17 条回复

CH
ChenChan1051

Does the retained completion carry the same attempt identity as the saved one?

12
NO
NoahChan1064

And was the first completion durably saved before the disconnect?

15
AN
AnikaBennett0769

Same attempt identity, Chen, with its result durably saved, Noah; the reconnect handler treats seeing the retained state as a fresh event regardless of that history

15
JU
JuliaBrown0935

Reconcile the retained identity with saved attempts before applying any change. A known matching completion should leave state and counts unchanged. Keep an unknown identity separate for review rather than assigning it to whichever housing is currently selected.

8
PR
PriyaCarter1003

What will the operator see during that review? I'd rather see one named housing awaiting reconciliation than a counter that briefly says the batch is finished while the program sorts itself out.

8
CH
ChenChan1051

What if the same identity returns a different result?

3
JU
JuliaBrown0935

Treat that as a conflict requiring the agreed review, not as permission to overwrite the saved result. Preserve both observations and their sources so the responsible person can investigate.

13
AN
AnikaBennett0769

Developer has matching, unknown and conflicting cases in the replay now; Priya, the proposed view identifies the held housing and review reason without moving it into the accepted total

23
NO
NoahChan1064

Does another reconnect preserve that unresolved reason?

7
PR
PriyaCarter1003

Noah's question matters for the next shift too. They shouldn't inherit an unexplained pending row after the first person saw a useful conflict message and went home.

25
AN
AnikaBennett0769

It initially lost the reason on a second reconnect; fixed persistence now keeps the unknown or conflicting observation visible with the original attempt history

2
CH
ChenChan1051

And no automatic inspection request from that path?

14
AN
AnikaBennett0769

None; replay asserts no request is sent, known completion leaves the total unchanged, and unknown or conflicting records remain awaiting the authorised decision

3
JU
JuliaBrown0935

Include a disconnect while the reconciliation result is being saved. A normal reconnect test can miss the boundary where one part of the record is written and another is not.

22
AN
AnikaBennett0769

Interrupted-save cases pass with the record either committed completely or still unresolved on reopening; the normal installed monitor has also reproduced the saved-completion case without recounting it

8
PR
PriyaCarter1003

Thanks for checking the normal monitor. Did the exported batch total follow it, or does the supervisor still receive the inflated version from another reporting path?

15
AN
AnikaBennett0769

Export matches the reconciled housing dispositions and retains the attempts beneath them; maintainer checked both after reconnect, and we've closed the duplicate-completion counting fault

9

参与讨论

欢迎来到 Application Robot

所有人都可以阅读论坛。登录或注册后即可发起讨论、回复或上传照片。

忘记密码?

注册账号即表示你同意我们的 使用条款 社区准则。请阅读我们的 隐私政策 ,了解我们如何处理你的信息。