our ur5e spacer wait has a request nobody seems to receive

FionaBarnes0586 · 28 Jan 2026, 16:14 UTC

Closed
FI
FionaBarnes0586
Our app says request sent. Fixture history shows no receipt. Seller wants another spacer-stop video. What would help?

21 replies

NO
NoraAli0235
Replying to FionaBarnes0586

What record shows the request was actually issued, rather than only queued by the app?

11 points
FI
FionaBarnes0586
Replying to NoraAli0235

Only the app message so far. I've asked its author to explain that.

6 points
DI
DineshAli0212
Replying to FionaBarnes0586

Can both authors identify the ordinary request and receipt signals and who owns them until the exchange is complete?

18 points
FI
FionaBarnes0586
Replying to DineshAli0212

They sent the interface notes. App briefly asserts request, then clears it without waiting for receipt.

5 points
AN
AnikaAbbott0073
Replying to FionaBarnes0586

Does the captured fixture record include that brief request?

7 points
ME
MeiAdams0168
Replying to FionaBarnes0586

Ask them to walk the missed-receipt case together. We had two suppliers demonstrate their own ends of an exchange successfully, then spend a meeting blaming the gap between them. One sent a brief indication; the other expected it to remain available until acknowledged. Both screenshots looked perfectly respectable. What finally helped was making them explain who kept each state, what confirmed receipt and what happened when the other side was absent.

8 points
FI
FionaBarnes0586
Replying to AnikaAbbott0073

No request in the fixture's captured interval, Anika. Authors are checking the actual exchange, not just the screenshots.

7 points
NO
NoraAli0235
Replying to FionaBarnes0586

Keep that absence separate from proof of why it was missed.

9 points
DI
DineshAli0212
Replying to FionaBarnes0586

Have they reproduced the short-request case in a controlled interface test with both ends observed?

-2 points
FI
FionaBarnes0586
Replying to DineshAli0212

Yes. Their test reproduces a missed request when the receiver checks after it has cleared.

15 points
AN
AnikaAbbott0073
Replying to FionaBarnes0586

What change are both authors agreeing?

19 points
FI
FionaBarnes0586
Replying to AnikaAbbott0073

Request retained until identified receipt, with timeout shown as unresolved rather than silently clearing and sending again.

12 points
NO
NoraAli0235
Replying to FionaBarnes0586

Include late receipt after timeout. It still belongs to the original request.

4 points
ME
MeiAdams0168
Replying to FionaBarnes0586

And ask what the operator sees while it is unresolved. Somebody still has to explain why the job is waiting without inviting a second request to make the message go away.

9 points
FI
FionaBarnes0586
Replying to MeiAdams0168

The revised display names the unresolved request and directs the operator to the shift lead.

19 points
AN
AnikaAbbott0073
Replying to FionaBarnes0586

Does the lead have an agreed decision process?

6 points
FI
FionaBarnes0586
Replying to AnikaAbbott0073

Yes. It includes checking retained receipt evidence with maintenance, not assuming timeout means nothing happened.

15 points
DI
DineshAli0212
Replying to FionaBarnes0586

Does the proposed exchange survive either application restarting without reusing an old receipt for a new request?

7 points
FI
FionaBarnes0586
Replying to DineshAli0212

Offline tests passed for delayed receiver, lost connection, late receipt and either restart, using distinct request identities.

11 points
FI
FionaBarnes0586
Replying to FionaBarnes0586

Installer completed the agreed station checks. Our spacer job no longer loses that request. Operators used the revised waiting explanation.

6 points

Discussion closed

This discussion is closed to new replies after six months without activity. Last activity: .