-
Notifications
You must be signed in to change notification settings - Fork 125
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Random ServerException #465
Comments
"Software caused connection abort" on mobile devices happens typically when a request is in flight, the app is backgrouded and the OS kills any open sockets to save resources. Nothing that gql could help with, that's just how mobile OS work. But in my experience, the issue is less problematic when using native http implementations. |
I'll look into both provided links for android, thanks. However the application run in kiosk mode, so it's never put in background, the issue is raised while user is interacting with the app so I'm very certain that the app is in foreground. Would you suggest that I should have a retry strategy for every request made ? What about the error occuring on web ? |
likely nothing related to gql, but underlying network, proxy, firewall ... issues. though you could try ErrorLink as workaround |
Hi, I made some progress on this lately by analyzing packets on my server. First thing I noticed was that there was a race condition with keep alive. Default keep alive with HTTP 1.1 is 5 seconds, if a request was made right after 5 seconds of inactivity, the server would close the tcp socket and gql http link would send a request in the same time that would become invalid. There should have been a retry mechanism in the lowest level of gql link for such cases because it's a common problem in HTTP 1.1 protocol with keep alive. Anyway, I decided to disable keep-alive altogether from the service side by returning Connection: Close instead of Connection: Keep-Alive but it appears to not be supported as shown in wireshark log below Indeed, as you can see at the beginning, it's all ok until packet 364 where server notify about the TCP socket to be closed which gql client respond with an ACK. As you can see aswell, the server responded in packet 363 with a Connection: Close header meaning client should close the tcp socket and not reuse it. However, client will send another HTTP request on the same socket at packet 431 two seconds later which would obviously result in a fail and a panic RST from the server To conclude, it looks like gql is missing a few logic in connection handling |
While on production, I receive random errors both in android and web (I haven't tested other platforms)
On web, it resembles to :
On android :
I've seen another issue (#358) but I doubt it's linked to CORS since my error is random and not systematic + it also occurs on android.
Relevant code :
gql being of class
Custom httplink to log link errors globally
The graphql object is not being rebuilt when the error occured so it can't be the cause of the issue too
At this point, I have no idea where to look at to understand and fix the issue.
Since it's very random (happen maybe 1/50), it's impossible for me to build a small repro as well
The text was updated successfully, but these errors were encountered: