Setting field level auth rule for model makes resolver always null that field for Mutation responses

[marmotgary]

How did you install the Amplify CLI?

No response

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

No response

Amplify CLI Version

14.0.1

What operating system are you using?

Ubuntu

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

No

Describe the bug

Using GraphQL Transformer V1. Adding a field level auth rule for a model makes the given field always be null for mutations. I'm not sure if this is a bug or expected behavior? If it is expected, help me understand why does this happen.

Example of the generated resolver:

TestModel.authField.res.vtl

## [Start] Checking for allowed operations which can return this field **
#set( $operation = $util.defaultIfNull($context.source.operation, "null") )
#if( $operation == "Mutation" )
$util.toJson(null)
#else
  $util.toJson($context.source.authField)
#end
## [End] Checking for allowed operations which can return this field **

Expected behavior

The field with auth rule should be returned in the response of Mutations as well.

Reproduction steps

1. Use transformer v1
2. Add following to the schema

type TestModel
  @model
  {
  id: ID!
  authField: String
    @auth(
      rules: [
        { allow: public, operations: [read] }
      ]
    )
}

3. Run codegen
4. See how the generated resolver TestModel.authField.res.vtl always sets the field to null on Mutations.

Project Identifier

No response

Log output

Details

# Put your logs below this line

Additional information

We should be able to work around this by overwriting the resolvers (https://docs.amplify.aws/gen1/react/tools/cli-legacy/overwrite-customize-resolvers/#overwriting-resolvers)

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.

[mrgrain]

Why would that not be expected? The access is explicitly set to read:

{ allow: public, operations: [read] }

[marmotgary]

Hello @mrgrain . Sorry for perhaps a little bad example, let me clarify. It does not matter what is in the field level auth rule, the result is always the same. If operation is Mutation, the given field is nulled on the response .
All of these fields has the same behavior:

type TestModel
  @model
  {
  id: ID!
  authField: String
    @auth(
      rules: [
        { allow: public, operations: [read] }
      ]
    )
  authField2: String
    @auth(
      rules: [
        { allow: public }
      ]
    )
  authField3: String
    @auth(
      rules: [
        { allow: private, provider: iam }
        { allow: groups, groupsField: "group" }
        { allow: groups, groupsField: "organizationId", groupClaim: "orgAdmin" }
        {
          allow: groups
          groupsField: "orgBusinessId"
          groupClaim: "orgBusinessAdmin"
        }
      ]
    )
}

And if the think of specifically this case: { allow: public, operations: [read] }, is it right to assume that the field is nulled at the response? At the request resolver we must make sure that the field isn't being altered (like it is now at the (Mutation.createTestModel.req.vtl), but shouldn't we return the actual value (read it)? The problem in encontering lies at the field level response resolver TestModel.authField3.res.vtl

We encountered this behavior in a case, where the frontend updates state based on the GraphQL response. There is no error or nothing, and we use auth rules similar to authField3 example above. The user doing the mutation has the permission to update the field, but after mutation it becomes null at the frontend state unexpectedly. If the user were to save again right after without noticing this, then the field will be accidentally nulled with the next mutation.