A user reported a crash in an app. Checking the logs, I saw a TimeoutError: Server code took too long, so I assumed it was temporary and asked him to try again. It failed again. He then mentioned he was out of the country on a slow connection and asked me to test it myself. When I did, it worked fine.
So, does the server timeout include the time spent on the client–server connection?
I would assume it includes the time to send back any information being returned. If that’s more than just a little, a slow connection would exacerbate it.
Since the crash happens on the server side, I assume the timeout only counts the client-server leg, not the response back, but I’m not sure, which is why I’m asking here.
That said, it’s odd that even accounting for just one direction of the round trip would cause failures every time (at least in the 5–6 attempts we tried).
I’m not entirely sure what this timeout is meant to protect against. My assumption is that it’s there to prevent long-running server tasks. If so, including client-server time doesn’t really address that, and it can create inconsistent user experience.
My default assumption was that the timeout was from the start of execution of a server function to the end of its execution. That includes the return statement, so I always assumed that at the very least marshaling of the return data by converting it to JSON and tossing it onto the outgoing network buffer was part of the timer. Possibly the actual transmission isn’t, but if slow network connections make the timeout happen more often, than the receipt of the return data by the client being part of the timeout would be one explanation.
No idea which way it is, of course, but I’ve also noticed slow network connections exacerbating the server timeouts.