When creating any part of the composite sort key for @index '<my index>', you must provide all fields for the key. Missing key: 'status'.

[adeldueast]

How did you install the Amplify CLI?

npm

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

v20.10.0

Amplify CLI Version

12.12.0

What operating system are you using?

windows 10

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

No

Describe the bug

When updating any part of the composite sort key for @index 'bySellerAndCreatedAtAndStatus', you must provide all fields for the key. Missing key: 'status'.

Then when providing status (forcefully)

When updating any part of the composite sort key for @index 'bySellerAndCreatedAtAndStatus', you must provide all fields for the key. Missing key: 'scheduledAtStart'.

Everytime i want to run a mutation on my model, I have to obviously provide the PK_SK but because the SK field createdAt_sk is also used in gsi, i always have to provide status and scheduledAtStart even tho i dont want to update them. This is really annoying, idk if its normal behaviour or not..

type Job
  @searchable
  @model(timestamps: { createdAt: "createdAt_sk", updatedAt: "updatedAt" })
  @auth(rules: [{ allow: private }, { allow: public }]) {
  job_pk: String! @primaryKey(sortKeyFields: ["createdAt_sk"])
  
  status: JobStatus! @default(value: "PENDING")
  scheduledAtStart: AWSDateTime!
  
  sellerId: ID!
    @index(name: "bySeller")
    # query jobs by seller, sorted by createdAt and status
    @index(
      name: "bySellerAndCreatedAtAndStatus"
      sortKeyFields: ["createdAt_sk", "status"]
    )
    # query jobs by seller, sorted by scheduled date (start to end)
    @index(
      name: "bySellerAndScheduledAtStartAndStatus"
      sortKeyFields: ["scheduledAtStart", "status"]
    )
    createdAt_sk: AWSDateTime!
}

Expected behavior

I dont really know but i dont think it should have to provide fields that i dont want to update.

Reproduction steps

1. create model with sortkeyfields using createdAt
2. also use that createdAt sortkeyfield on other GSIs
3. perform mutation on a record providing the pk and sk and updating a random field that is not related to any gsi (just add a ranom field to for test purpose e.g test: String!

Get an error because you have to also provide all the fields used in other gsi that uses createdAt sortkey field

Project Identifier

No response

Log output

# Put your logs below this line

Additional information

related to aws-amplify/amplify-cli#9666 ?

Before submitting, please confirm:

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

[adeldueast]

This is even worse than I thought.

There is a case where i want to update a model field but because of this bug i have to PROVIDE other fields that I DO NOT want to update.

Now I ahve to make sure to provide the latest version of these fields, because my local state might be stale and this could cause major issues in my business logic.

If i just want to update field1 , i should be able to perform a mutation on field1 alone, not have to provide field2 and make sure field2 is not stale.

In one of my lambda i LITTERALY go fetch the updated version (to get the source of truth) and provide those requried field in my mutation to make sure im inserting latest data and not corrupting anything..

[ykethan]

Hey,👋 thanks for raising this! I'm going to transfer this over to our API repository for better assistance 🙂

[AnilMaktala]

Hey @adeldueast, Are you still experiencing this issue?

[AnilMaktala]

Hey 👋 , This issue is being closed due to inactivity. If you are still experiencing the same problem and need further assistance, please feel free to leave a comment. This will enable us to reopen the issue and provide you with the necessary support.

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.