Closed vkammerer closed 1 month ago
Thanks for testing this, as I was wondering what the behaviour in this case is.
How have you fixed it? I assume the solution is, in the case of Flutter, to add a life cycle state listener and when the app is in foreground again, refetch the data of all streams again.
Just to be sure: I assume that the stream behaves the same as an on change listener, right?
@dippa-1 I haven't fixed it, instead I decided not to use supabase for now. It should be not the responsibility of the user of this library to fix it, I guess that the supabase team is aware of that and plans to address this issue some time in the future.
indeed this stream supabase.from('messages').stream(primaryKey: ['id'])
closes after app stays in background for a while and then comes back to foreground.
With #1019 being merged now, these issues should be solved now. You can try them by upgrading supabase_flutter
to 2.7.0
. If you still experience any issues, please create a new issue.
When an iOS app goes in the background, it looses network after a while (about 90 seconds according to my tests with the simulator). If new rows are then created in a Supabase table that the app listens to, the app doesn't receive the data (which is expected). When the app reconnects after idling, it starts receiving table addition events (which is expected), but it emits a representation of the data without the events that happened while is was offline (which is not expected).
I looked a bit at the code and can see that
supabase-flutter
manages its own cache, and that it manages internal representations of a table on atomic events like "INSERT" for example.Maybe a solution could be to fetch the whole table after a reconnection? Or maybe to pass a reference to the previous message for all atomic events, so that the app can ensure that it hasn't missed one?
See video below for an example: the "third message" is ignored, and an incorrect representation of the messages list is emitted. https://github.com/supabase/supabase-flutter/assets/1177483/5b44500b-d3eb-476b-8946-f02d4029c8f4
Steps to reproduce the behavior:
Expected behavior The stream emits a correct representation of the data.
Version: I am on MacOS