our ur5e spacer wait has a request nobody seems to receive
FionaBarnes0586 · 28 Jan 2026, 16:14 UTC
21 replies
What record shows the request was actually issued, rather than only queued by the app?
11pointsOnly the app message so far. I've asked its author to explain that.
6pointsCan both authors identify the ordinary request and receipt signals and who owns them until the exchange is complete?
18pointsThey sent the interface notes. App briefly asserts request, then clears it without waiting for receipt.
5pointsDoes the captured fixture record include that brief request?
7pointsAsk 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.
8pointsNo request in the fixture's captured interval, Anika. Authors are checking the actual exchange, not just the screenshots.
7pointsKeep that absence separate from proof of why it was missed.
9pointsHave they reproduced the short-request case in a controlled interface test with both ends observed?
-2pointsYes. Their test reproduces a missed request when the receiver checks after it has cleared.
15pointsWhat change are both authors agreeing?
19pointsRequest retained until identified receipt, with timeout shown as unresolved rather than silently clearing and sending again.
12pointsInclude late receipt after timeout. It still belongs to the original request.
4pointsAnd 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.
9pointsThe revised display names the unresolved request and directs the operator to the shift lead.
19pointsDoes the lead have an agreed decision process?
6pointsYes. It includes checking retained receipt evidence with maintenance, not assuming timeout means nothing happened.
15pointsDoes the proposed exchange survive either application restarting without reusing an old receipt for a new request?
7pointsOffline tests passed for delayed receiver, lost connection, late receipt and either restart, using distinct request identities.
11pointsInstaller completed the agreed station checks. Our spacer job no longer loses that request. Operators used the revised waiting explanation.
6pointsDiscussion closed
This discussion is closed to new replies after six months without activity. Last activity: .