@key values not being populated in DynamoDB

[frankclaassen]

Describe the bug
values for @key definitions are not being updated and get something like this as value ${ctx.args.input.fieldName1}#${ctx.args.input.fieldName2}

Amplify CLI Version
4.42 & 4.43

To Reproduce
create a new record for a type with combined @key definition

Expected behavior
Expect actual values to be populated

Desktop (please complete the following information):

• OS: Win10
• Node Version:12.9

[frankclaassen]

This is a critical issue as I am now sitting with a heap of production data with garbage data values!!!!

[edwardfoyle]

Hi @frankclaassen I'm unable to repro this with a simple schema with a compound @key definition. Can you provide your GraphQL Schema?

[frankclaassen]

Hi @edwardfoyle

Here is an example schema where I had the problem (I had to revert to amplify 4.41 for the problem to go away):

type Person
@model(subscriptions: null)
@key(name: "byNameByDate", fields: ["firstName","lastName","birthDate"], queryField: "getPersonByNameByDate")
{
  id: ID!
  firstName: String!
  lastName: String!
  birthDate: AWSDate!
}

The composite key field ended up as described in my issue instead of having firstName#lastName#2009-01-01

[frankclaassen]

@edwardfoyle how can I fix this issue until the cli gets fixed? This is causing a major headache in my production environment

[frankclaassen]

I can confirm this is an issue in the latest version of cli 4.44.0 as well

[frankclaassen]

further confirmation is that it seems the issue is only with creating new records, updating a record gets the composite key values set correctly

[frankclaassen]

just to add: I also have auth rules on the schema which I suspect may be the cause????, here is the full schema with auth rules and when testing, I am signed in as a user in the Admins group

Note: I also added a lambda function as a trigger on this dynamodb table, not sure if that has any impact on the create action

type Person
@model(subscriptions: null)
@key(name: "byNameByDate", fields: ["firstName","lastName","birthDate"], queryField: "getPersonByNameByDate")
@auth(
    rules: [
      {
        allow: groups
        groups: ["Admins", "Users"]
        operations: [create, delete, update]
      }
      {
        allow: private
        provider: iam
        operations: [create, read, update, delete]
      }
      { allow: private, operations: [read] }
    ]
  ) {
id: ID!
firstName: String!
lastName: String!
birthDate: AWSDate!
}

[yuth]

@frankclaassen I am unable to reproduce this. Could you share the mutation that you use to create the Person. Also do you run the Mutation in AppSync console or do you use a different client to run the mutation?

[yuth]

Does this happen to records already existing in the table or does this happens to new records added?

[frankclaassen]

@yuth this only happens when I create new records. I have the issue both in my react app and when I create a new record in the AppSync console. -- Well, as I was writing this comment I was actually busy updating the code for my trigger function and noticed the issue is no longer there and records are now being created correctly..... Gotta love ghost bugs that appear and then disappear

[frankclaassen]

@yuth seems the bug only went away in my dev system and not prod and I have no idea why.

[frankclaassen]

@yuth Further testing and investigation has found that the issue in fact came in when I updated the record in the trigger function, I did not specify values for the keys used in composite keys. This results in no error being thrown for some reason and my data ends up with ${ctx...} values.

IMHO, it is incorrect (and a bug in my opinion) of the resolvers to update composite keys when none of the values used in composite keys have changed

[yuth]

@frankclaassen Could you provide more information on when this trigger function gets exectued and what mutation gets executed when running the trigger function? Also what authorization mode is used in the trigger function

[frankclaassen]

ype Person
@model(subscriptions: null)
@key(name: "byNameByDate", fields: ["firstName","lastName","birthDate"], queryField: "getPersonByNameByDate")
@auth(
rules: [
{
allow: groups
groups: ["Admins", "Users"]
operations: [create, delete, update]
}
{
allow: private
provider: iam
operations: [create, read, update, delete]
}
{ allow: private, operations: [read] }
]
) {
id: ID!
firstName: String!
lastName: String!
birthDate: AWSDate!
}

@yuth as you can see from the schema, iam roles have full access to create, update, read, delete on my table. The trigger was added to using amplify add function and gets executed whenever there is a change in dynamodb. My code checks if I need to take action and if so, it will create a login and update the record with the userid. The issue came in with updating the record and not specifying the values for firstName, lastName, birthDate because these didn't change. This is where the logic in the resolvers makes no sense to me, why update the composite keys when the values for them have not changed? By updating the composite key, it is doing an unnecessary write to the associated GSI and does not follow the well known principle of KISS, Keep It Simple S...

[edwardfoyle]

@frankclaassen Thanks for all the details. I have been able to repro the issue with the following schema

type Person
@model(subscriptions: null)
@key(name: "byNameByDate", fields: ["firstName","lastName","birthDate"], queryField: "getPersonByNameByDate")
{
  id: ID!
  firstName: String!
  lastName: String!
  birthDate: AWSDate!
  otherField: String
}

Then using the AppSync console, run the following mutation:

mutation MyMutation {
  createPerson(input: {birthDate: "2020-02-02", firstName: "Amy", lastName: "Body", id: "myid"}) {
    birthDate
    createdAt
    firstName
    id
    lastName
    otherField
    updatedAt
  }
}

go to the corresponding DynamoDB table and observer that the record is correct. Then run this mutation:

mutation MyMutation {
  updatePerson(input: {id: "myid", otherField: "some new data"}) {
    birthDate
    createdAt
    firstName
    id
    lastName
    updatedAt
    otherField
  }
}

Go to the DynamoDB table again and observe that the GSI sort key column of the record now has the unsubstituted VTL

Marking this as a critical bug

[edwardfoyle]

The fix for this has been released in CLI version 4.44.2. You will need to re-generate the VTL resolvers using amplify api gql-compile and then amplify push. It's possible you will need to use amplify push --force if the CLI doesn't detect a change to the schema.

[github-actions]

This issue has been automatically locked since there hasn't been any recent activity after it was closed. Please open a new issue for related bugs.

Looking for a help forum? We recommend joining the Amplify Community Discord server *-help channels for those types of questions.