ParseObject saved multiple times on slow internet connection

[Kiwifed0r]

Hi,

I'm having an issue with parse and very slow network connection. This can be reproduced with the emulator when using cellular network and setting it to GSM and signal strength 'None'. Now, when saving a ParseObject, the call goes through and the ParseObject shows up in the dashboard but the client doesn't get the answer before the timeout. This means that Parse tries again and saves it another time and so on until the maximum number of retries is reached. And finally the callback is called reporting an error. Setting the network to LTE and signal strength 'Good' at some time results in a positive callback for the most recent try.

One solution which I tried is to set the timeouts to 60 seconds. This works and the answer from the server reaches the client on very slow internet before the timeout.
Another possible solution would be to tell Parse not to retry.

Does anyone have any other suggestions how to solve this issue?
Does it make sense for Parse to retry saving an object after a failure? There's no way to be sure whether or not the object was saved.
For fetching data on the other hand retrying is fine.

This only happens when using https.

Parse version: 1.16.3

[montymxb]

We'll have to see about this one, it's a bit tough when working under very poor or interrupted network conditions to ensure much of anything. I wonder if maybe preventing retries would even help, as you still may not be able to tell if the object was even created or not. It would be nice to deliberate and see if there is a reasonable solution for this.

[Kiwifed0r]

I ran some tests on iOS and I was able to reproduce the issue on iOS aswell. The only difference is that the timeouts are different. It seems that the default timeouts on iOS are a lot higher (60 seconds) compared to Android (okhttp, 10 seconds?). To reduce the chance of this happening I will set the timeouts to 60 seconds for now. The connection has to be incredibly poor for this to happen with 60 seconds timeout and it shouldn't happen very often but still not impossible.

I played around with setting number of retries to 0 and it also prevents saving the object multiple times but then the problem is that we still don't really know what's going on and the 10 seconds timeout is too less.

The best 'solution' for now is to increase the okhttp timeout.

[montymxb]

@Kiwifed0r hopefully you're able to keep the issue at bay with your timeout patch. It's not the best but if it works in your case it will have to do for the moment. Since, this could happen to any sdk I'm wondering if a server side fix should be considered...

We had a similar issue brought up in parse server where a response wasn't returning to the client, resulting in multiple retries and duplicate objects. Unfortunately if the server cannot return a response for some reason there's not a ton we can do about it :/. It's implied that we trust the connection to completion, but if becomes strained some undesired behavior (such as this) can become evident.

[lukyanov]

@montymxb @Kiwifed0r That's why usually non-idempotent requests are not retried by default.

Due to the nature of HTTP protocol and client-server architecture, from the client point of view there are always 3 types of responses: 1) object has been successfully saved, 2) object has not been saved, 3) the status of object is unknown (it could be saved or not). This will always be like this. There will always be situations when the client doesn't know. You CANNOT fix this on the client or on the server side.

The only requests that can be safely retried are read requests. All the rest types are subject to business logic consideration. The app should decide, not SDK. So my proposal would be to remove retry logic from SDK altogether.

[Jawnnypoo]

100% in agreement that the retry should be configurable by the client, disabled by default

[CoderickLamar]

If we pass our own okhttp Builder, does it override any other settings?

Basically, I'm deciding whether it makes more sense to override that actual timeout code by forking, or to pass my own okhttp Builder. When I passed my own OkHttpClient.Builder, I had some unintended issues, but I wasn't entirely sure if these were related.

[Jawnnypoo]

The timeout unfortunately does not come from OkHttp but is deeper in the SDK.

[univ3rse]

Any news on this, or combined effort we can make to improve this?
We are very keen to get a solution for this, as we constantly run into timeouts for certain things.

[univ3rse]

I added the SDK locally so I could fool around a bit easier, I set the three timeouts to the internal member of OkHttpBuilder before build() is called and it seemed to work fine. Tried an external OkHttpBuilder and it seemed to work as well.
I do seem to remember that an external one did not work in the past for some reason, but have not traced the commits to see if there were any changes.

This should be fairly easy to add as an extension of the Parse.Configuration.Builder and check when the builder is being loaded if there are any custom timeouts to be set.(In ParsePlugins after line 109)

[thunderwin]

someone fixed this issue....?? please

[mtrezza]

@thunderwin The issue still exists. A workaround is to:
a) disable retries: http://parseplatform.org/Parse-SDK-Android/api/com/parse/Parse.Configuration.Builder.html
b) Implement logic yourself if possible in your use case; to prevent for example multiple writes you can set a UUID for the object so the server won’t create it multiple times.