-
Notifications
You must be signed in to change notification settings - Fork 369
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
Firestore: Expose sufficient state to manually restart a Listen operation #2513
Comments
I'll certainly treat it as a bug for now, but I'd like more information about each case. Caveat for all of this: while I implemented the API, I'm not on the Firestore team so some subtleties may be outside my knowledge. I'll let the Firestore team know about this so they can check my assertions. Case 1 I'd expect updates to be visible, but potentially bundled up. For example, I think this is a reasonable sequence of events updating a single value in a single document:
Note the absence of "callback fired with value 2". In other words, I'd expect this to be a way of keeping up to date with the contents of a document, not to observe the sequence of changes in the document. Could you clarify whether you're seeing that behaviour, or whether you're not seeing the "callback fired with value 3" item? Case 2 I'd expect the status to change to faulted after some timeout (I don't know exactly how long) and then not recover. If you're seeing it only change to faulted when the network connection recovers, that's a bug - but it's not a bug for the fault to be permanent once the task status has become faulted. |
Thank you for replying. This is exactly the behavior I get for each case: Case 1 Value set to 1 Case 2 It happens just like you described. The status changes to faulted after some timeout and then it does not recover. The problem is, I would expect auto recovering in this case, which does not happen. I think that at least a callback to notify the application should be implemented, so the listener can be manually restored by the application. |
Okay, let's deal with case 2 first. This is out of scope for this library. The expectation is for this library to be used for server-side applications, so there's relatively little connection-handling and offline support, which the client-side SDKs would provide. There is a callback of sorts that the connection has failed, in that the task changes state to For case 1, do you have an example timing log? If the time between the network recovering and the value being set to 4 is very short, that list looks okay - but if you have to change the value in order to see the update, that's a different matter. Any more information you have would be useful for investigating this - obviously it's somewhat tricky to set up for testing, unless I can find some way of faking the connection failing just for the Listen part. |
For case 1, I have tested two different scenarios: Network shutdown This scenario can be emulated by disconnecting the network cable or by disabling the network interface on Control Panel\Network and Internet\Network Connections. The
Connection timeout This scenario can be emulated by disconnecting the WAN port of the LAN router or by setting the default gateway of the network interface to an unreachable IP address. The
This is the console application that produced the output above:
|
After testing this solution more carefully, I found out that there was an issue with my network which was causing the strange behavior of not receiving updates after a short network outage (30-60 seconds). So I confirm that case 1 is actually working as expected. The callback is fired whenever the connection is restored before timeout. Only three cases cause the listener to fail:
Based on that, it is possible to conclude the API is behaving as expected and therefore there is no real bug. |
Regarding case 2, it seems pretty simple to restart the listener manually. The only issue is, if the same So my suggestion is to leave this thread as feature request to allow the manual creation of a listener using an existent state. |
Thanks very much for all your diligence in investigating this - it's much appreciated. Making this a feature request works for me. I've edited the title of the issue and the first comment. I haven't looked into how hard it would be to expose enough state to resume listening - and there may be other reasons why it's not feasible at the server side, such as resume tokens only being relatively short-lived - but I'll ask the Firestore team what they think. |
In the mean time, I would like to share a temporary workaround which I am using to auto recover faulty listeners. It basically follows Jon's suggestion to add task continuation to detect faulty listeners. The listener is then re-created using the original parameters. There is very little work for the caller to do. Instead of calling Important: Because the listener is recovered by creating a complete new listener, there is no state preservation. So you may want to introduce a post fault callback:
Finally the code:
|
I've spoken with the Firestore team about this, and we'll wait until we hear more users requesting this feature so that we can make sure that the design handles a wide selection of use cases. #3381 adds this feature request to the backlog, so I'll close this issue. Many thanks for all the thoughtful comments though - even if we can't implement all feature requests, it's great to have users who are so involved. |
Edited 2018-09-21: This was originally a bug report, and the context is preserved for informational purposes. It's now a feature request to permit clients to perform recovery from long-lasting network outages.
I have found two issues which indicate that
FirestoreChangeListener
does not handle network outage properly:FirestoreChangeListener.ListenerTask.Status
is set toTaskStatus.Faulted
.I was expecting the API to handle network outage automatically. I am not sure if that is a bug or a feature request.
The text was updated successfully, but these errors were encountered: