The first reconnect read finds a completion already in our plate-check history, then adds another completed check. I want its job identified without clearing the retained result or resending inspection.
Retained UR5e completion counted on every new connection
ZaraAllen0308 · 2026年3月22日 00:37 UTC
主帖中文翻译暂不可用，以下显示英文原文；回复保留原文。 查看英文原文
11 条回复
Compare the retained attempt identity with saved processed history. What identifies the result besides the completion flag? The connection's first observation is not necessarily the producer's first completion.
0分Job counter and plate label survive with the result. Our seen list belongs to the connection and starts empty.
13分Move that check to retained history, but confirm the job counter's scope first. Does it start again when its producer restarts?
5分Yes. Producer restart resets the counter, so counter plus plate label could match an earlier run too.
13分Have the author provide a retained run identity with the attempt reference. Making the laptop remember more won't fix a producer identity that gets reused.
1分Keep the old ambiguous entries unresolved where the run cannot be recovered. Do not invent a run link merely to make the new key fit existing history.
17分Has the author settled that run identity, Zara?
3分Yes. Revised records include producer run and attempt identities. Reconnect now reconciles known results through saved history; old entries without a recoverable run link stay marked for review.
3分Test a repeated delivery within one run and the same counter in a new run. The first should be one record; the second must not disappear as a duplicate.
13分And assert that reconnect sends no new inspection request. The bookkeeping repair should not acquire a helpful retry on its way through the code.
14分Both run-scope cases passed, including application restart. The recorded commissioning replay also sends no new request on reconnect. Saved history and displayed check totals agree; unmatched old entries remain visible for review.
9分讨论已关闭
此讨论已连续六个月没有活动，现已关闭新回复。 最后活动： .