Hm, it makes sense and I guess that will be the same in case of restart or connection throttling. So if there is no way how to handle connection problems through that delegate method the clients should detect connection problems in some other way. One Idea would be to ignore connectivity at all and just react on the response from object .save() that could be rejected by cloud code function if the object in server database is newer. In other words, if the server would reject a .save() request, the client app would realise that the data in device might be obsolete and would try to refetch actual state and restart LiveQuery. But here I stuck again.
First I tried:
let client = ParseLiveQuery.getDefault()
client?.close()
client?.open(completion: { error in
print("error opening LQ: \(error)")
})
the client?.close() seems to close the task, but keeps client?.isSocketEstablished = true what might be correct behaviour. Although I would expect that in this case it would set to false (at least by URLSessionWebSocketDelegate, but there the method didCloseWith does not get called also, even the connection to server is live). Is there a reason, why there is not set the status(.closed) here? Or should there be any URL Session invalidation in there?
Because when the client?.open(completion:...) tries to open the client again, the task will receive and error on line 59:
Optional
- some : Error Domain=NSURLErrorDomain Code=-999 “cancelled” UserInfo={NSErrorFailingURLStringKey=https://felse.b4a.io/, NSLocalizedDescription=cancelled, NSErrorFailingURLKey=https://felse.b4a.io/}
This error does not occur on the fresh LQ connection during app launch and as there is no error handling after line 506, the code just fall through without setting isConnecting
on fresh app start are the task values the same as on the later open attempt
Printing description of task:
LocalWebSocketTask <9A3BC5D5-…7F05C1967>.<1>
Printing description of encodedAsString:
“{“op”:“connect”,“applicationId”:“coYfu…Ug4p”,“clientKey”:“L8PDq…87gl”,“sessionToken”:“r:5a…baf8”,“installationId”:“7ec2…c9ca”}”
Perhaps the .close() does not let the server know that the socket is closed and that’s why it is being canceled during later .open()…? As I am not experienced enough I am not sure if that is desired or e bug.
Even if I would not worry about .close() and .open() and would just unsubscribe and subscribe again with
try subscription!.query.unsubscribe()
the .send() function receives an error for both unsubscribe and subscribe on line 73/77:
Optional
- some : Error Domain=NSPOSIXErrorDomain Code=57 “Socket is not connected” UserInfo={NSErrorFailingURLStringKey=https://felse.b4a.io/, NSErrorFailingURLKey=https://felse.b4a.io/}
as if has no error handling, this again falls through:
Printing client booleans shows as previously that socket is established:
testing subscription: Optional(ParseSwift.SubscriptionCallback<Felse.PrsProfile>)
testing LiveQuery isConnected: Optional(true)
testing LiveQuery isConnecting: Optional(false)
testing LiveQuery isSocketEstablished: Optional(true)
testing LiveQuery isSubscribed: Optional(true)
testing LiveQuery isPendingSubscription: Optional(true)
That’s why I believe there is no other way around than solving the socket status. And when the URLSessionWebSocketDelegate doesn’t call didCloseWith (what I understood it cannot when connection is dead or server down) then only manual reset would help, right? In that case I would need to clarify if here bellow line 130 should not be a manual status change to closed or invalidation of the URL:
