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

Our UR5e startup sends the bracket request a second time

OscarAli0184 · 2026年4月16日 08:42 UTC

回复讨论
OS
OscarAli0184
Our app crashed after sending a bracket check. Pending survived; the result didn't. Startup resends it automatically.

21 条回复

DA
DanielBaker0478

Keep sent-but-uncertain requests out of automatic resend. Can the application look up the original attempt by its identity? The bracket may have been inspected while the file still said pending.

3
OS
OscarAli0184

It has the original request ID. The developer is disabling resend for that uncertain state.

0
JA
JaneBennett0771

Also establish what evidence marks a request as definitely never sent. A crash before saving a receipt can leave the same empty field as a request that never reached the sender.

9
CE
CeciliaBurke

Where is the bracket now? Keep its identity with the uncertain attempt while the software question is being worked through, so another shift does not treat it as fresh uninspected stock.

-2
TO
TobyBaker0492

Does the request ID reach the receiving application, or is it only a local log label? That decides whether the lookup can really find this attempt.

14
OS
OscarAli0184

Toby, it reaches the receiver. Cecilia, the bracket is identified and held with the inspection lead.

4
AN
AnikaBennett0769

Give the reconciliation work an owner and time, otherwise everyone will agree to hold it and nobody will have a job to finish

6
EL
ElenaBell0688

For the teaching example, show known never-sent and sent-but-uncertain side by side. The second one should not look like a broken version of the first. I would have the covering person explain the difference before showing the authors' answer.

13
IS
IsabelBennett0735

Include a real never-sent request in the software test too. Removing every route to submission would stop the duplicate neatly and leave you with a very quiet inspection station.

2
AM
AmaraArcher0426

Has the original lookup returned anything yet?

5
OS
OscarCarter0967

And keep the bracket's current disposition visible beside the lookup. A receipt alone should not make the held part appear accepted in the operator view.

7
OS
OscarAli0184

Amara, receipt found, no result returned yet. Inspection lead owns reconciliation and the bracket remains held.

16
HA
HazelArcher0397

We had a queue of uncertain samples gradually renamed new work because nobody wanted the awkward list on screen. Same physical samples, cleaner-looking queue. I'd keep yours visible with the owner, even once the software fix makes new work behave properly.

14
JA
JaneBennett0771

Oscar Ali, leave the receipt as receipt found until its outcome is reconciled. The query has answered whether it was received; you still need the result and its link to this bracket.

6
EL
ElenaBell0688

Hazel, that's a useful example to discuss with the covering person. Also show a genuinely reconciled item leaving the hold list, so the lesson isn't that uncertain work must sit there forever.

5
OS
OscarAli0184

Original result recovered and matched. Quality accepted that bracket and recorded its release from hold. Software checks continue.

5
TO
TobyBaker0492

Thanks for closing the physical bracket question too. Does the repaired startup preserve that result when reopened, rather than recreating the old pending entry?

7
OS
OscarAli0184

Yes. Known result, uncertain send, missing receipt and genuine never-sent cases passed offline, including reopening.

17
IS
IsabelBennett0735

Run those through the installed application with the maintainer before calling the startup repair complete. Include an unavailable lookup: it should preserve uncertainty, not quietly return never sent.

19
OS
OscarAli0184

Installed checks passed, including unavailable lookup. Covering operator followed the uncertain hold and recognised the reconciled result without prompts.

14

参与讨论

欢迎来到 Application Robot

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

忘记密码?

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