Critical: DataStore GraphQL owner sub stored in wrong, duplicated format (sub::sub instead of sub)

[NiklasMeetyu]

Description

Dear Team,

currently our app launch is delayed because of this issue. We're using the AWS Amplify Gen 1 DataStore (android/iOS) in Flutter with Cognito Auth and store the sub (i.e. userid) automatically alongside our data. The graph ql schema does that for us automatically. See here:

type UserSettings
@model
@auth(
rules: [
{
allow: owner
ownerField: "ownerID"
operations: [create, update, delete, read]
},
{ allow: public, provider: apiKey, operations: [update, read] }
]
) {
id: ID!
name: String
language: String
ownerID: ID @index(name: "byOwnerID", queryField: "getUserSettingsByOwnerID")
}

In the AWS console we can see the data in DynamoDB where it is finally loaded automatically for us as part of the Amplify DataStore logic.

Issue:
We noticed, that in most "rows" in these Dynamo DB tables, the sub is stored wrongly like this:
sub::sub (e.g. hgusas-181273-...-1212::hgusas-181273-...-1212)
However, we would expect (which only in some case works)
sub (e.g. hgusas-181273-...-1212)

The mix up of two different formats leads to issues on our end. Can you please help us understand why the format is inconsistent? Adjusting our functions to identify duplicated data seems like a "dirty" solution that doesn't address the real problem. What do you think?

Kind regards,
Niklas

Categories

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

Steps to Reproduce

1. Add GraphQL like we did with Cognito based Auth tags
2. Create the type from Step 1 (for different users and experiment for some what happens when you change it for the same user)
3. Observe the data in DynamoDB and observe the "ownerID" field. You should see that the format is often sub::sub and only sometimes the correct, expected sub.

Screenshots

No response

Platforms

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

Flutter Version

3.27.0

Amplify Flutter Version

^2.3.0

Deployment Method

Amplify CLI (Gen 1)

Schema

type UserSettings
  @model
  @auth(
    rules: [
      {
        allow: owner
        ownerField: "ownerID"
        operations: [create, update, delete, read]
      },
      { allow: public, provider: apiKey, operations: [update, read] }
    ]
  ) {
  id: ID!
  name: String
  language: String
  ownerID: ID @index(name: "byOwnerID", queryField: "getUserSettingsByOwnerID")
}

[tyllark]

Hello @NiklasMeetyu thank you for taking the time to open this issue. We will try to reproduce the issue and get back to you.

[tyllark]

Hello @NiklasMeetyu, sorry for the delay but I've been unable to reproduce the issue thus far. Could please provide code samples and additional steps to reproduce please.

I'm using your schema to generate users with the default and manually set OwnerIds:

Future<void> _createUserSettingManualOwnerId() async {
    var userSetting = UserSettings(
      id: uuid(),
      name: 'User ${_rng.nextInt(1000)}',
      language: _languages[_rng.nextInt(_languages.length)],
      ownerID: getRandomString(20),
    );

    try {
      await Amplify.DataStore.save(userSetting);
    } catch (e, st) {
      Logger.log('Create Exception', '$e - $st');
    }
  }

  Future<void> _createUserSettingDefaultOwnerId() async {
    var userSetting = UserSettings(
      id: uuid(),
      name: 'User ${_rng.nextInt(1000)}',
      language: _languages[_rng.nextInt(_languages.length)],
      //ownerID: null,
    );

    try {
      await Amplify.DataStore.save(userSetting);
    } catch (e, st) {
      Logger.log('Create Exception', '$e - $st');
    }

Then I'm updating the owner to a new value. (Ive also tried updating the UserId with the same value and with null)

Future<void> _updateUserSettingOwnerId() async {
    try {
      final userSettings = await Amplify.DataStore.query(UserSettings.classType);

      for(UserSettings usersetting in userSettings) {
        usersetting = usersetting.copyWith(ownerID: null,);
        await Amplify.DataStore.save(usersetting);
      }
      print('hi');
    } catch (e, st) {
      Logger.log('Create Exception', '$e - $st');
    }
  }

[NiklasMeetyu]

Hi @tyllark Thank you for investigating the bug!

What we do (nothing/automatic ownerID assignment on creation and update):

// NEW SETTING
final newUserSettings = UserSettings(
name: onboardingData['name'] ?? '',
language: "en"
);
await Amplify.DataStore.save(newUserSettings);
// --> Note we do not set the ownerID (as the graphql declaration means its handled behind the scenes)

// UPDATE SETTING
final oldSettings = await getUserSettingsFromDataStore();
final updatedSettings = oldSettings.copyWith(
name: userSettings.name ?? oldSettings.name,
language: userSettings.language ?? oldSettings.language,
);
try {
await Amplify.DataStore.save(updatedSettings);
} on DataStoreException catch (e) {
throw Exception('Failed to update user settings: ${e.message}');
}

vs. what you do:
// NEW SETTING
_createUserSettingDefaultOwnerId()
//--> Note that this is what we do above
// UPDATE SETTING
// your code
//--> you update the userSetting with the same owner id. We do not touch this field at all.

Does this provide you with helpful context @tyllark ?

Kind regards,
Niklas