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