@index directive without parameters works in iOS (Swift) app but not web (React) app

[chrisbonifacio]

How did you install the Amplify CLI?

No response

If applicable, what version of Node.js are you using?

16.13.0

Amplify CLI Version

10.6.2

What operating system are you using?

Mac

Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.

No manual changes made

Describe the bug

Following the documentation for adding GSIs to a GraphQL schema: https://docs.amplify.aws/cli/graphql/data-modeling/#configure-a-secondary-index

type RoomSchedule
  @model
  @auth(
    rules: [
      { allow: public }
    ]
  ) {
  id: ID!

  roomID: ID! @index

  startTime: AWSDateTime
}

Deploying a schema with an index without the optional parameters, name or queryField, seems to work in native Swift SDK Amplify app but is causing unexpected behavior in React web app.

In the web app, the GSI is being used by DataStore as the primary key but a primary key already exists.

Adding the name and queryField parameters seems to fix the issue and DataStore uses the correct primary key on the React app.

roomID being considered a primary key (perhaps mistaken for custom primary key?)

Error thrown during sync process

While debugging, it seems this if statement is being skipped over because DataStore is not auto-generating a value for the id field.

Expected behavior

DataStore uses the correct primary key

Reproduction steps

1. setup DataStore-enabled GraphQL API and schema with a model including an @index directive, no extra parameters
2. amplify push
3. start DataStore in a web app

Project Identifier

92c3dcf409a6854477c23599d6e4a2cc

Log output

``` # Put your logs below this line ```

Additional information

No response

Before submitting, please confirm:

• [X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
• [X] I have removed any sensitive information from my code snippets and submission.

[chrisbonifacio]

I was able to reproduce this issue consistently, marking as a bug.

Interestingly, the first time I save a record, I can see the graphql mutatation sent to AppSync succeed and an id was auto-generated.

  const createRoomSchedule = async () => {
    const roomSchedule = await DataStore.save(
      new RoomSchedule({
        roomID: "456",
        startTime: new Date("2023-01-30T05:30:00").toISOString(),
      })
    );

    console.log("Saved roomSchedule: ", roomSchedule);
  };

Network Activity

Record persisted to local store on first save (ID was autogenerated)

However, in indexedDB, DataStore is still incorrectly using the roomID GSI as the primary key or "key path".

And, running the same DataStore.save code again, replaces the previously "correct" record with this one where the id field is now missing altogether and the roomID is acting as the primary key.

[AnilMaktala]

Hey @chrisbonifacio, can you please re-try after enabling feature flag in cli.json? refer docs here

[chrisbonifacio]

@AnilMaktala unfortunately, that flag was already enabled ☹️ this is still an issue. In talking with @manueliglesias , it seems this schema should not be deployable for a DataStore enabled API to begin with. We may have to throw an error on compilation along with a message on how to correct if @index is in the schema and missing parameters when conflict detection is enabled.

[chrisbonifacio]

For anyone experiencing this issue:

in the mean time you can work around this by adding a name property to the @index directive in your schema.

 type RoomSchedule
   @model
   @auth(
     rules: [
       { allow: public }
     ]
   ) {
   id: ID!
   roomID: ID! @index(name: "byRoom")
 }

You'll need to call amplify push --allow-destructive-graphql-schema-update after making the schema change