GraphQL interfaces breaking builds/deploys since 11

[whunter]

How did you install the Amplify CLI?

npm

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

20.17.0

Amplify CLI Version

12.13.0

What operating system are you using?

Mac

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

updated nodejs runtime in lambda

Describe the bug

Beginning in Amplify 10 (I think) we started seeing this warning on builds because we're using an interface in our schema.graphql. They would not cause builds to fail though. We've had our builds pinned to 10.8.1 which does still support interfaces.

2024-10-14T18:57:36.877Z [WARNING]: ✖ There was an error initializing your environment.
2024-10-14T18:57:36.883Z [INFO]: 🛑 Unknown type GenericRecordType for field items. Did you forget to add the @model directive

Beginning in Amplify 11, this began causing builds to fail.

And we can no longer pin to 10.8.1, because it seemingly tries to build node14 lambdas regardless of what we put in our cloudformation templates. So those break now as well and we can't build our app at all.

Expected behavior

Amplify build/deploy shouldn't require that all GraphQL return types have @model. That isn't always the case. (interfaces | unions)

Reproduction steps

1. Deploy an Amplify app with an interface in the schema.graphql
2. Receive warning/error message

Project Identifier

Amplify app id: d2ysrrdhih4bgc

Log output

``` # Put your logs below this line 2024-10-14T18:57:36.877Z [WARNING]: ✖ There was an error initializing your environment. 2024-10-14T18:57:36.883Z [INFO]: 🛑 Unknown type GenericRecordType for field items. Did you forget to add the @model directive ``` ### Additional information _No response_ ### Before submitting, please confirm: - [X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue. - [X] I have removed any sensitive information from my code snippets and submission.

[ykethan]

Hey,👋 thanks for raising this! I'm going to transfer this over to our API repository for better assistance 🙂

[AnilMaktala]

Hi @whunter  👋 , thanks for raising this issue.we are working on reproducing the issue. Could you please run below command and send us the project identifier. amplify diagnose --send-report. please refer here

[whunter]

Hi @AnilMaktala, Broken app: Project Identifier: 22892ffad33ef7cc8282e9383c97ace5

If it helps, the app below built, deployed, and is currently running using the same schema (more or less). We still have it pinned to 10.8.1 in build settings and I assume it hasn't been deployed since before the nodejs14.x lambda runtime reached end of support. If we tried to update it now, it would break either because of that nodejs runtime error if we tried Amplify <=10 OR it would break because of the interface in the schema in Amplify > 10.

Project Identifier: f70ad9709259f0ce4eade22db19e620b

Thanks for your attention to this. We've been using an interface for years in Amplify with no problems. I probably wouldn't even be reporting this now if we could still just build/deploy w/ 10.8.1, although that isn't ideal.

[whunter]

@AnilMaktala fwiw, I have no idea what I'm talking about. but it looks to me like amplify push and build both are running codegen as part of their processes. They both throw the same warning/error message when a schema uses an interface. In push it raises a warning but still continues. In build it throws an actual error that fails the build. To me that looks like the only difference.

[AnilMaktala]

Hey @whunter, Thanks for sharing the project identifier. We can reproduce this issue in both latest and 10.8.1 versions. are you sure no other changes was done in the schema?

As workaround, Can try creating two search queries for models (collection and Archieve) implementing the interface instead one search query using the common interface?

[AnilMaktala]

After further investigation, I found that despite the amplify codegen models failing locally, the Amplify push was successfully deployed in version 10.8.1.

[whunter]

Hi @AnilMaktala Pushing a backend using amplify push works for us as well. Our blocker is when we try to actually build/deploy a branch either manually through the amplify web console or via amplify-github hooks on a commit.

If I'm understanding your suggestion correctly, I don't think that will fix our issue. The use case for our interface is to allow us to return both Collection and Archive records from the same query. Then users can filter them as needed. Example here: https://digital.lib.vt.edu/search. You can filter with "Category" on the left.

[AnilMaktala]

Hi @whunter, Thanks for providing the additional information. We will investigate further to identify the root cause.

[sundersc]

Hey @whunter, Codegen's generate models command is failing if you use interfaces in the GraphQL schema. Prior to 11.x, this command was executed at the end of amplify push only if you have datastore enabled. But for some reason, it is executed for every push starting 11.x (still investigating the reason). That's what causing the problem in your case.

As a temporary solution, we have got a tagged release to skip modelgen if datastore isn't enabled. Please use the below version and let us know if you still run into issues.

$ npm i -g @aws-amplify/cli@12.13.1-disable-modelgen.0

[whunter]

@sundersc Hey, that worked! Thanks so much. 🥳

I just deployed an empty app with a stripped down schema but it references an interface, so it should be good? I'll try deploying some of our actual dev apps and see what happens

[whunter]

@sundersc I've updated our development apps and this version has resolved our issue. Works great. Can we just stay pinned to this version until this (or similar) makes it's way into an official release? Thanks!

[sundersc]

That's a great news. Yes, this version is good to use.

Regarding the interfaces support, it is still not supported on 'generate models' command. But this shouldn't impact if you are not using datastore or amplify studio. We will keep this issue open to address the bug with generate models command. Once again, thanks for bringing this issue to our notice.