Amplify-cli: Error when providing _version attribute on updates when key attribute is defined in schema

Created on 22 May 2020  路  3Comments  路  Source: aws-amplify/amplify-cli

On a table that's backed by a versioned DynamoDB table (to be used with datastore) when we run GraphQL mutations via the appsync console we can't seem to make any updates.

  • If we supply the _version attribute we get a "Updating _version field can not be set from the client" error.
  • If we run a mutation without providing the _version attribute the _version attribute on the record increments but no data is updated.

I believe I tracked the issue down to us having a @key("id") attribute in the amplify api graphql schema. We had originally had wanted to use a custom partition and sort key but that's also not possible so I changed it to just "id".

If we remove the @key("id") attribute things work correctly and the generated dynamoDB schema is the same. Is it currently not supported to have any definition of the key when using versioned sources?

This works:

type Note2 @model @auth(rules: [{ allow: owner }]) {
  id: ID!
  note: String
  owner: String
}

This does not work:

type Note3 @model @key(fields: ["id"]) @auth(rules: [{ allow: owner }]) {
  id: ID!
  note: String
  owner: String
}
bug graphql-transformer review

Most helpful comment

I have the same issue with a model with the following key
type Notifications @key(fields: ["key"])

What I found after some digging is that the problem is in the resolver Mutation.updateNotification.req.vtl that is generated for the model. Since the model has a custom key it adds this in the top of the file:

#set( $modelObjectKey = {
  "key": $util.dynamodb.toDynamoDB($ctx.args.input.key)
} )

Later when it is identifying the key fields it creates the bug:

#if( $modelObjectKey )
  #set( $keyFields = [] )
  #foreach( $entry in $modelObjectKey.entrySet() )
    $util.qr($keyFields.add("$entry.key"))
  #end
#else
  #set( $keyFields = ["id", "_version", "_deleted", "_lastChangedAt"] )
#end

This cause the $keyFields to only contain ["key"], instead of ["key", "_version", "_deleted", "_lastChangedAt"]. This again causes that it tries to update the __version_ field instead of just check the version for it.

I solved it now by copying the _Mutation.updateNotification.req.vtl_ to the custom resolver folder and changed the #if( $modelObjectKey ) part to:

#if( $modelObjectKey )
  #set( $keyFields = ["_version", "_deleted", "_lastChangedAt"] )
  #foreach( $entry in $modelObjectKey.entrySet() )
    $util.qr($keyFields.add("$entry.key"))
  #end
#else
  #set( $keyFields = ["id", "_version", "_deleted", "_lastChangedAt"] )
#end

After this change, it seems to work fine

All 3 comments

This looks to be specific to Amplify CLI, I have transferred this to their repo.

I have the same issue with a model with the following key
type Notifications @key(fields: ["key"])

What I found after some digging is that the problem is in the resolver Mutation.updateNotification.req.vtl that is generated for the model. Since the model has a custom key it adds this in the top of the file:

#set( $modelObjectKey = {
  "key": $util.dynamodb.toDynamoDB($ctx.args.input.key)
} )

Later when it is identifying the key fields it creates the bug:

#if( $modelObjectKey )
  #set( $keyFields = [] )
  #foreach( $entry in $modelObjectKey.entrySet() )
    $util.qr($keyFields.add("$entry.key"))
  #end
#else
  #set( $keyFields = ["id", "_version", "_deleted", "_lastChangedAt"] )
#end

This cause the $keyFields to only contain ["key"], instead of ["key", "_version", "_deleted", "_lastChangedAt"]. This again causes that it tries to update the __version_ field instead of just check the version for it.

I solved it now by copying the _Mutation.updateNotification.req.vtl_ to the custom resolver folder and changed the #if( $modelObjectKey ) part to:

#if( $modelObjectKey )
  #set( $keyFields = ["_version", "_deleted", "_lastChangedAt"] )
  #foreach( $entry in $modelObjectKey.entrySet() )
    $util.qr($keyFields.add("$entry.key"))
  #end
#else
  #set( $keyFields = ["id", "_version", "_deleted", "_lastChangedAt"] )
#end

After this change, it seems to work fine

@UnleashedMind I see that is marked as fixed. This is a pretty big issue. When are we going to use the fixed version?

I executed the following:

npm install -g @aws-amplify/cli@latest

And if the problem are in the resolver... is there any command to regenerate those?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ffxsam picture ffxsam  路  3Comments

adriatikgashi picture adriatikgashi  路  3Comments

gabriel-wilkes picture gabriel-wilkes  路  3Comments

mwarger picture mwarger  路  3Comments

amlcodes picture amlcodes  路  3Comments