Say when the phone is not on a network at all - #135
Merged
Merged
Conversation
Owner: "app smart enough to find why not able to connect. as i said earlier wifi change, or internet not available or server not responding or server not allowing (403) etc. proper notifications is mandatory." Wi-Fi and mobile data both off is the one cause a phone can be certain of without asking anybody, and the one a waiter can fix in five seconds. It was the one case the outage screen never mentioned. Told that the till is not responding while their Wi-Fi is simply off, somebody goes and restarts a computer that is working perfectly. Checked before the network comparison, which needs an interface that a phone with everything switched off does not have. WHAT I DID NOT SHIP, and why. A 403 is its own cause and he is right about that: a dead address gives a connection error, only a server sends a status, so a refusal means the till is ON, on this Wi-Fi, and turning this phone away - usually because the shop has run out of handset slots. The fix is a licence screen, not a power button. The connect sheet already says which till refused. The outage screen does not, and a phone already signed in never reaches the connect sheet. I wrote that wording, then found the overlay never appears at all for a refusing pinned till, and took it back out rather than leave an unreachable message behind - which is the exact fault the rest of this work keeps finding. Where a mid-service refusal actually surfaces is not yet known, and guessing would be worse than the gap, so it is named in the spec file instead of half-built. Try now already retries the server it is on: it always did, and nothing proved it, so a change to the candidate order could have quietly turned it into "go and find a different till". There is a test now.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Four causes, one symptom, and each has a different person doing a different thing about it. Here is the honest state of all four after this PR.
What this adds
Wi-Fi and mobile data both off. The one cause a phone can be certain of without asking anybody, and the one a waiter can fix in five seconds. It was the one case the outage screen never mentioned, so somebody whose Wi-Fi was simply off was told the till is not responding and went to restart a working computer.
Checked before the network comparison, which needs an interface that a phone with everything switched off does not have.
And a test that Try now retries the server it is already on. It always did, but nothing proved it, so a change to the candidate order could have quietly turned Try now into "go and find a different till".
What I did not ship, and why
A 403 is its own cause and you are right about that. A dead address gives a connection error; only a server sends back a status. So a refusal means the till is on, on this Wi-Fi, and turning this phone away, usually because the shop has run out of handset slots. The fix is a licence screen, not a power button.
The connect sheet already says which till refused. The outage screen does not, and a phone already signed in never reaches the connect sheet.
I wrote that wording, then found the overlay never appears at all for a refusing pinned till, so the message would have been unreachable. That is the exact fault this work keeps finding elsewhere, so I took it back out rather than leave dead text behind. Where a mid-service refusal actually surfaces is not yet known, and guessing would be worse than the gap, so it is named in
server-resolution.spec.jsinstead of half-built.Tests
477 unit tests and 328 browser tests pass, including two new ones: no network at all is named before anything else, and Try now retries the current server. Tamil added.