Amplify-cli: Missing/broken resolvers for createdAt and updatedAt

[FizzBuzz791]

Describe the bug
The CLI automatically generates a subscription, including the createdAt and updatedAt fields, but when triggered, GraphQL returns errors "Cannot return null for non-nullable type 'AWSDateTime!'..."

Given this type isn't in my schema, I can't even control it.

Amplify CLI Version
4.21.1

To Reproduce
Follow this workshop up until this step, but make sure to use the latest Amplify version.

It should fail at the last instruction on the linked page; "Try uploading another photo"

Expected behavior
createdAt and updatedAt are resolved correctly.

Desktop (please complete the following information):

• OS: Windows
• Node Version: 12.16.3

[attilah]

@FizzBuzz791 thanks for reporting this issue, we'll look into it.

[FOMSON]

Same issue...

Unpredictable behaviour too - seems to work well in dev environment (on localhost) and breaks on prod.

[FOMSON]

It seems that AppSync GraphQL schema does somehow include createdAt and updatedAt fields [even though I do not mention them in my schema]...

It seems to solve itself time-to-time, i.e. createdAt and updatedAt just disappear from the scheme... maybe with push it with a little tweak to the schema [I just added empty line breaks to my schema and pushed with Amplify CLI]

Amplify Docs, here - https://docs.amplify.aws/cli/graphql-transformer/directives, talk about these two fields being automatically added... But why are they now "forced"?..

THIS SEEMS TO BE A PERSISTENT ISSUE THAT BREAKS FRONTEND with unexpected errors.

I think, I found a workaround - explicitly added createdAt and updatedAt to my schema as not required (no ! next to them), which seems to work yet, and both createdAt and updatedAt get automatically updated on mutations...

The problem [still] is that nowhere it says that one must add createdAt and updatedAt to their schema.

[chantlong]

Can confirm this happened to me. APIs that used to work suddenly don't work because of non-nullable updatedAt error.
Added updatedAt into the schema as @FOMSON said to fix it. Kind of scary if this happens in prod suddenly.

[SwaySway]

@FizzBuzz791 A few questions here to better understand the issue
I was not able to get this error as I'm able to queries just fine. Did you start using the tutorial with one version and the continue with an updated version?
Before auto population of date fields the CLI would still add createdAt and updatedAt, records should still have the timestamps added. Was the schema setup such that createdAt and updatedAt were not included?

[FizzBuzz791]

I don't think I changed versions, but I do remember using the latest version rather than the version specified in the tutorial.

My "workaround"/"fix" is as per the other responses; explicitly add the fields to the schema. I think I also tried adding the field to the generated queries, but that's a bad hack as it'll get removed/overwritten next time I change the schema and regenerate the queries.

[SwaySway]

@FizzBuzz791
Are there null values for createdAt and updatedAt in the created dynamodb table?

[henninghoyer]

I can confirm the issue. I have a subscription for an onCreate Event that looks like this:

subscription OnCreateProject {
    onCreateProject {
      id
      number
      name
      description
      createdAt
      updatedAt
    }
  }

In the DynamoDB Table the fields createdAt and updatedAt get correctly populated by the resolvers but in my frontend I get the "Cannot return null [...]" error mentioned by @FizzBuzz791. Everything works fine if I remove createdAt and updatedAt from the subscription.

Amplify Version
4.26.0

[FizzBuzz791]

@SwaySway - same as @henninghoyer above, all the fields seem to be fine in the table. I _thought_ that the subscription was missing those fields and I had to add them to get rid of the issue, but @henninghoyer has reproduced the issue more recently than I have, so maybe my memory is wonky.

[SwaySway]

@henninghoyer @FizzBuzz791 If the resolvers are adding those fields it's possible the mutation's selection set does not include those fields.

Does createProject include createdAt and updatedAt?

[chantlong]

Just to reinforce how big of an issue this is, my schema.graphql had 4-5 tables and none of the tables had updatedAt explicitly defined.
updatedAt does get autopopulated whenever an item is created, which is fine.
All I did was remove 1 attribute which is not a timestamp from one of the tables and after amplify push it broke all my APIs to all 4-5 tables with the "Cannot return null for non-nullable type 'AWSDateTime!' within parent 'Table Name'" error. I had to fix it by adding the updatedAt attribute into the schema.graphql to revive the APIs.
Before I did amplify push I did update my CLI to 4.2X... don't remember. So I'm assuming the push made the resolvers mandatory to have updatedAt

[teezeit]

having the same experience. The createdAt & updatedAt fields are autogenerated in queries.js, but when null in dynamo, it creates an error: "Cannot return null for non-nullable type: 'AWSDateTime'.

[henninghoyer]

@SwaySway Yes, the mutation does include both createdAt and updatedAt

export const createProject = /* GraphQL */ `
  mutation CreateProject(
    $input: CreateProjectInput!
    $condition: ModelProjectConditionInput
  ) {
    createProject(input: $input, condition: $condition) {
      id
      number
      name
      description
      status
      entries {
        items {
          id
          owner
          duration
          date
          description
          projectID
          createdAt
          updatedAt
        }
        nextToken
      }
      createdAt
      updatedAt
    }
  }
`;

[SwaySway]

@henninghoyer
On running the mutation are there values returned for createdAt and updatedAt? Is it only in a subscription when you see that error?

[henninghoyer]

@SwaySway I just checked, the mutation does indeed return both values, it is only the subscription.

[SwaySway]

@henninghoyer The result of the subscription should be the same as the mutation. This sounds like a potential issue with the service. I would recommend their forum. https://forums.aws.amazon.com/forum.jspa?forumID=280

Closing this as a dependency issue with Appsync.

[duncangroenewald]

So is there a solution for this problem ?

[FOMSON]

So is there a solution for this problem ?

https://github.com/aws-amplify/amplify-cli/issues/4613#issuecomment-658474460

Plus the rest of the threat may be useful...

[duncangroenewald]

So is there a solution for this problem ?

#4613 (comment)

Plus the rest of the threat may be useful...

Huh ! this is #4613