observeQuery isSynced value is incorrect after DataStore.clear()

[Jordan-Nelson]

Description

The value for isSynced returned from observeQuery will be true after calling DataStore.clear() even while a new sync is in progress. isSynced should probably reset to false.

Categories

• Analytics
• API (REST)
• API (GraphQL)
• Auth
• Authenticator
• DataStore
• Storage

Steps to Reproduce

No response

Screenshots

No response

Platforms

• iOS
• Android
• Web
• macOS
• Windows
• Linux

Flutter Version

n/a

Amplify Flutter Version

1.1.0

Deployment Method

Amplify CLI

Schema

No response

[Jordan-Nelson]

Current work around is to manually wait for the sync process to complete after calling clear. For example:

await Amplify.DataStore.clear();
await Amplify.DataStore.start();
await Amplify.Hub.availableStreams[HubChannel.DataStore]!
    .firstWhere((event) => event.eventName == "ready");

[Jordan-Nelson]

Originally observed in #3054 (comment)

[jamilsaadeh97]

Hi @Jordan-Nelson
I've been experiencing the same issue but the work around is not very "clean" in my case.

I can use await Amplify.Hub.availableStreams[HubChannel.DataStore]!.firstWhere((event) => event.eventName == "ready"); on the first app launch(signed in session/signed out session), but the issue is when a user logs out, I clear the DataStore and when a user logs back in I should also call await Amplify.Hub.availableStreams[HubChannel.DataStore]!.firstWhere((event) => event.eventName == "ready"); , and this will make the login experience very very slow. I'm also worried if by mistake DataStore was ready before calling this, the user will get stuck waiting indefinitely.

Furthermore, I'm using syncExpressions too, so basically if I use this work around, DataStore will keep getting cleared and started multiple times.

For an experimental app, I guess that's okay to some extent but for a production app, I think this is a very bad code architecture. Do you have any suggestion on how to do this in a clean way?

Is resetting "isSynced" after clearing DataStore an easy fix on your side or it might take time?

Thank you!

[jamilsaadeh97]

UPDATE

Awaiting DataStore to be ready is taking ~21 seconds in my application and that's seriously a bad user experience.

[dgagnon]

The initial load speed of the datastore is also an issue we are facing. The only way to mitigate it that we found is to use a restrictive Sync Expression, load the base info needed, then reset the Sync Expression to get a full load. Any other suggestion in speeding up the load time ?

[Jordan-Nelson]

The sync time for DS will depend on how many model types are used, how many models exist, the auth rules you have set up (if any), the selective sync expression used (if any), and of course the internet speed/latency.

@jamilsaadeh97 Do you have a use cases that require offline first support, or were there other reasons you chose to use DataStore (opposed to using GraphQL API directly)? We are collecting feedback in #3180 about offline first and caching related use cases as we consider expanding support for these use cases to Web and Desktop. Please feel free to leave feedback there. Even if your use case is mobile specific, it would be good to collect the feedback.

@dgagnon - I see you already left feedback and noted that you are specifically looking for offline first support.

[jamilsaadeh97]

@Jordan-Nelson In my opinion offline first approach is, most of the time, the best approach since it can handle slow internet connections and is fastest when the caching is there.
I will leave a feedback there about my use cases.