DataStore initial sync slower after recreating auth and schema has owner-based permissions

[erickotsuka]

Description

In a project I am working on, I had to update the sign in method from email and password to phone number and password. The project was also using a GraphQL API with DataStore for offline capabilities, and the schemas had owner-based permissions. To do that, I had to first remove the auth category and recreate it using phone number sign in. When I updated the environment, the initial DataStore sync was a lot slower. However, when I created a new environment based on the updated environment, the initial sync was normal in the new environment.

Categories

• [ ] Analytics
• [ ] API (REST)
• [ ] API (GraphQL)
• [x] Auth
• [ ] Authenticator
• [x] DataStore
• [ ] Notifications (Push)
• [ ] Storage

Steps to Reproduce

I've created a small Flutter app to reproduce this problem, it is here: https://github.com/erickotsuka/slow_sync_demo.

In this repository, there are 3 branches: master, phone-number-login and new-env.

• The master branch is the "original" project, using email sign in and owner-based permissions. The README on this branch contains the steps used to setup. I also included the amount of time it took for the initial query to complete 3 times (clearing the app's storage on Android Emulator before each time).
• The phone-number-login branch is the project after updating to use phone number sign in. The README on this branch contains the master branch's content plus the steps used to update to phone number sign in. And, again, the amount of time for the initial query to complete 3 times, using the same strategy.
• The new-env branch is the project after creating a new environment based on the changes in phone-number-login branch. The README follows the same pattern.

In conclusion, originally the initial query took an average of 2273 ms. After updating the same environment to use phone number sign in, the initial query took and average of 12722 ms. On the new environment created based on the updated environment, the initial query took an average of 2971 ms.

The version of the amplify CLI used was 12.10.3.

Screenshots

No response

Platforms

• [ ] iOS
• [X] Android
• [ ] Web
• [ ] macOS
• [ ] Windows
• [ ] Linux

Flutter Version

3.22.0

Amplify Flutter Version

1.8.0

Deployment Method

Amplify CLI

Schema

type User 
  @model
  @auth(
    rules: [
      { allow: owner }
      { allow: public, provider: apiKey }
    ]
  ) {
  id: ID!
  name: String!
  owner: String @auth(
    rules: [
      { allow: owner, operations: [read] }
      { allow: public, provider: apiKey, operations: [create, read, update, delete] }
    ]
  )
}

[Jordan-Nelson]

Hello @erickotsuka. Thanks for taking the time to open the issue. I have a few questions:

1. Do all environments have the same number of items in Dynamo? Initial sync will take longer if there are more items in Dynamo.
2. In each test are you starting from a fresh app install? If the app is already installed on the device and an initial sync had previously occurred, DataStore will only sync the changes since the last sync rather than doing a full sync.
3. Are you also seeing slower sync times for iOS for the phone-number-login env?
4. Are you trying to apply field level auth? DataStore does not support field level auth. There is an open feature request for this. See: https://github.com/aws-amplify/amplify-flutter/issues/3459

[erickotsuka]

Hello, @Jordan-Nelson

1. Yes, all environments have only one item in DynamoDB.
2. It's not a fresh install, but the storage was cleared before each test (in app settings).
3. I did not test on iOS.
4. Only for the owner field, but the field level authorization worked on this field. Before applying it, the owner was able to change to a different owner. Once it was applied, the owner could not longer do that.

[Jordan-Nelson]

@erickotsuka Thanks for the info. We will attempt to reproduce the issue with the specified info.

[Jordan-Nelson]

@erickotsuka - I was able to reproduce this. I observed about ~600ms sync times initially and then ~2000ms sync times after updating the back end. I created a new Amplify app (rather than a new env) and observed ~600ms sync times again. I see this on both iOS and Android.

Are you able to work around this for the time being by creating a new amplify app or env?

[erickotsuka]

@Jordan-Nelson - For now we have this work around, specially since this change required the deletion of the user pool. However, it could be a issue if an update that does not require the deletion of the auth category caused this increase in sync times, since in production this work around would not be possible.

[Jordan-Nelson]

@erickotsuka thanks for clarifying