App says no internet connection? Check the request timeout
An app told users to check their wifi when the network was fine: our own timeouts were shorter than the work. How to tell, and what we changed.
If your app says there is no internet connection when the network is fine, the usual cause is a request timeout: the app gave up waiting before the server finished, and then blamed the wifi. The first thing to check is how long the slowest normal request takes, against how long the screen is willing to wait.
Here is how that looked in one app, and what fixing it took.
Someone opens your app, presses the button that asks the AI to draft something, waits, and is told there is no connection. They know there is. They are on the same wifi as everything else, and the key they are using for the service is a good one.
That is what happened in a children’s learning app, where a parent uses AI to draft a lesson. The message was wrong, and so was the blame. The connection was fine. The app had simply given up before the answer arrived, and by then the answer had already been generated and paid for, and was thrown away.
A second fault of the same kind sat beside it. The first person to sign in after the server restarted got a failure, and the sign-in screen again told them to check their wifi. Nobody needs a support call to find out that a message like that is a lie.
What was actually going on
Both were timeouts that we had set ourselves.
The app cut off every request after 20 seconds. Behind the button, the server tries the AI providers in turn, and it pays for each one that fails before the one that answers. Measured on the real keys, that was 0.7 seconds on the first, 5.6 on the second and 15.2 on the third. That adds up to 21.6 seconds against a budget of 20.0. The third provider answered, the app had already walked away, and the result was discarded.
The sign-in fault was the same shape. The server checks a sign-in against Google’s published signing keys, and fetches them once after each start. On the first fetch that took 11.7 seconds, and the server’s own limit was 10. So it failed, and the first person through after every restart saw an error.
What we changed
The four routes that call an AI provider now allow 120 seconds. We made the timeout a kind of network error inside the app, so nothing that already handled network errors had to change, and we stopped the app claiming the network was down when the delay was ours.
For sign-in, the limit went to 20 seconds with one retry, and if the keys are already held from earlier, a slightly old copy is used instead of failing everyone during a hiccup. The sign-in screen now gives three different messages, so a server fault no longer says “check your wifi”.
What it did not fix
A 120-second limit means a person may wait up to two minutes before hearing that something is wrong. We did not shorten the chain of providers, and the log does not record any change to how long the slowest path takes. We only stopped giving up on it.
Nor did we remove the cost of trying several providers. The server still pays for each one that fails before the one that works. The fix made sure the answer, once paid for, arrives.
How to check your own app
- Ask how long the slowest normal request takes, including every fallback behind it. If the server may try three services in turn, the screen cannot give up after the time of one.
- Compare that with how long the screen waits. If the second number is not clearly larger than the first, some of the failures you hear about are your own.
- Read the error messages. “No connection” is a claim. If your own system is the one that stopped waiting, the message should say so, because a wrong message sends a person to fix their wifi and sends you nowhere.
- Ask what happens to work that finished after the app gave up. Here it was paid for and thrown away.
Where this ends up
This is the kind of fault that turns up when an app calls AI services and has to live with their timing, which is the work described on our AI and data assistants page.