fix: un-require required input fields with @default

[p5quared]

Handoff Notes:

Issue

If an input GQL schema has a required field that has a default e.g.

# Pseudo-GQL
name: String! @default(value: "anonymous")

the schema at the end of the transform still considers these fields to be NonNullable on CreateInput types.

# Pseudo-GQL
type CreateUserInput {
  ...fields,
  name: String! # <- This should be Nullable, since we have provided a default value
}

Reproduction

1. Create CDK app
2. Define bin/cdk-test.ts:

#!/usr/bin/env node
import 'source-map-support/register';
import * as cdk from 'aws-cdk-lib';
import { Stack } from 'aws-cdk-lib';
import { AmplifyGraphqlApi, AmplifyGraphqlDefinition } from '@aws-amplify/graphql-api-construct';

const app = new cdk.App();

const stack = new Stack(app, 'CoffeeStack');

new AmplifyGraphqlApi(stack, 'CoffeeQueue', {
	definition: AmplifyGraphqlDefinition.fromString(/* GraphQL */ `
    type CoffeeQueue @model {
      id: ID!
      name: String! @default(value: "anonymous")
      order: String
    }
  `),
	authorizationModes: {
		defaultAuthorizationMode: 'API_KEY',
		apiKeyConfig: {
			description: 'Api Key for public access',
			// @ts-ignore 
			expires: cdk.Duration.days(7)
		},
	},
});

3. cdk synth or cdk deploy
4. Outputs:

# model-schema.gql
type CoffeeQueue @model {
  id: ID!
  name: String! @default(value: "anonymous")
  order: String
}

type CoffeeQueue {
  id: ID!
  name: String!
  order: String
  createdAt: AWSDateTime!
  updatedAt: AWSDateTime!
}
...
input CreateCoffeeQueueInput {
  id: ID
  name: String! # <- This should be Nullable
  order: String
}

These inputs are reflected in the AppSync console, where you will not be able to run create mutation without providing a name in this case.

Q/A

• Why do apps using defaults currently work?
  • Default values are provided in resolvers via VTL
• Why has nobody noticed this?
  • There have been issues raised in the past (A field with @default directive is required on the generated create entity mutation input amplify-codegen#390). The lack of recent issues may be because you have to specify a field is required and provide a default, however our gen2 docs state you cannot use both .default() and .required() on the same field.
• Why wasn't this PR merged?
  • The blocker for this PR is that we aren't positive of the downstream effects i.e. whether or not this is a breaking change.
  • Personally, I feel fairly confident that this change would not break customer apps, but I was not able to confirm any/all downstream consumers of the output schema to guarantee this.

PR

Description of changes

Un-require required input fields that have @default applied. Also update the corresponding snapshot to document this behavior.

Prior to this change, a copy of the input object was being modified but ctx.output was not being updated with the new input.

CDK / CloudFormation Parameters Changed

n/a

Issue #, if available

aws-amplify/amplify-codegen#390

Description of how you validated changes

Fixed a test snapshot and edited code to pass it.

Checklist

• PR description included
• yarn test passes
• Tests are changed or added

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[phani-srikar]

There is one more case to consider here which is when the @default is applied to fields part of a composite primary key. Gen2 doc or this Gen1 doc is more explicit about the schema with composite primary key.

[p5quared]

Added a separate check scanning over sortKeyFields.

[phani-srikar]

nit: can we refactor this check to see if the field is a primary key into it's own method that can be re-used between this method and the one above?