Comment 1 for bug 1413269

Bug #1409995 affected our smartscopesproxy service, which starts with user session (keeps running in the background) and handles network requests by creating QNetworkAccessManager instance with every new request. So, in theory, since QNAM was re-created for every request, it should not be affected by temporary network issue and should recover with another request, assuming network becomes available. What we observed however was a permanent failure: if the problem occurred after reboot, no network requests were passing through anymore. QNetworkAccessManager / QNetworkReply signals wouldn't report any progress or error and were just stuck.

While reproducing that bug (which wasn't hard - it would happen every 2-3 reboots of the phone) I found out that it couldn't be reproduced if I just killed smartscopesproxy process and let upstart respawn it - I tried killing it around 20 times in a row, and every time it was serving network request correctly. That suggests the problem may have something to do with startup sequence.