Generated models with fields with @connection directive form invalid GraphQLRequest when attempting to update

[sandasai]

Describe the bug
After generating models via amplify codegen models from a schema model with @connection directive, the update mutations will fail. This is due to the fact that the @connection fields are defined on the models and will be passed into the mutation.

An error will occur along of the lines of: The variables input contains a field name \'notes\' that is not defined for input object type \'UpdateTaskInput\'

To Reproduce
Steps to reproduce the behavior from scratch:

1. Setup base project amplify with API
2. Create and deploy schema:

type Task @model {
  id: ID!
  title: String!
  description: String
  status: String
  notes: [Note] @connection(keyName: "byTask", fields: ["id"])
}

type Note
  @model
  @key(name: "byTask", fields: ["taskId"])
{
  id: ID!
  content: String!
  taskId: ID!
  task: Task @connection(fields: ["id"])
}

3. Create a basic Task:

let task = Task() // ... 
Amplify.API.mutate(request: .create(task))  { // ...

4. Attempt to update the task

Amplify.API.mutate(request: .update(task))

Observed Behavior
The update results in a GraphQL error since notes will be passed into the mutation, even though it's only used to establish a one-to-many relationship.

Resulting error message:

GraphQLResponseError<Task>: GraphQL service returned a successful response containing errors: [Amplify.GraphQLError(message: "The variables input contains a field name \'notes\' that is not defined for input object type \'UpdateTaskInput\' ", locations: nil, path: nil, extensions: nil)]

Expected Behavior
The update should be successful

Environment(please complete the following information):
Xcode Version: 12.0.1

Device Information (please complete the following information):
Tested in simulators

[drochetti]

Hey @sandasai thanks for reporting this and for providing all the useful details of your use case.

I was able to reproduce it using your schema and I have put a fix out in the PR #837

I wasn't able to reproduce the issue in our unit tests schema though, which is something intriguing. I'm still trying to find the difference between your schema and ours. Regardless, the code change in that PR is a valid one and will be part of the next release.

[drochetti]

The PR #837 was merged, this issue will be closed after a release with the fix it out.

[drochetti]

Hey @sandasai, 1.4.0 was released and contains the fix to this issue.