New Behavior (?) from Appsync -- Nested null @hasOne objects in createObject and updateObject (but NOT getObject or listObjects) resolvers throw errors on required attributes: "Cannot return null for non-nullable type: 'ID' within parent '<my nested model>'"

[DeezNutz2]

How did you install the Amplify CLI?

N/A

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

N/A

Amplify CLI Version

N/A

What operating system are you using?

N/A

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

No manual changes made

Describe the bug

type Company
@model
)
{
    id:                     ID!
    owner:                  ID!
    centralInfrastructureId: ID
    centralInfrastructure:   Infrastructure      @hasOne     (   fields:     ["centralInfrastructureId"]      )  <-- this one
}

type Infrastructure
@model
)
{
    id:                     ID!
    owner:                  ID!
    companyId:              ID      @index      (   name:   "byCompany"     )
    # company:                Company @belongsTo  (   fields: ["companyId"]   )  # no longer used
} 

If i do a createCompany with a null centralInfrastructureId, the 'nested' @hasone centralInfrastructure will be null.
The createCompany and updateCompany resolvers will then choke on the required fields from the nested Infrastructure.

mutation CreateCompany(
  $input: CreateCompanyInput!
  $condition: ModelCompanyConditionInput
) {
  createCompany(input: $input, condition: $condition) {
    id
    owner
   ...
    centralInfrastructureId
    centralInfrastructure {
      id  <-- choke
      owner  <-- choke
      ....

      createdAt <-- choke
      updatedAt <-- choke
      __typename
    }

    createdAt
    updatedAt
    __typename
  }
} 

gives me

{
"data": 
... 
id: <some new id>,
centralInfrastructureId: null,
centralInfrastructure: null,
...
"errors": [
    {
      "path": [
**        "createCompany",
        "centralInfrastructure",
        "id"**
      ],
      "locations": null,
      **"message": "Cannot return null for non-nullable type: 'ID' within parent 'Infrastructure' (/createCompany/centralInfrastructure/id)"**
    },
   ... ( also 'owner' and 'updatedat' and 'createdat')

  ]
} 

If I remove the 'required' fields from the mutation return values, the errors go away.

To be clear, the mutation is successful but I think these errors are new, I believe, because I've been handling them so that any errors returned from graphql throw exceptions all over my app and I've only seen these exceptions in my app in the last few days.

But that's like a GetCompany, right? what happens if i do a GetCompany?

query GetCompany($id: ID!) {
  getCompany(id: $id) {
    id
    owner
    ...
    centralInfrastructureId
    centralInfrastructure {
      id
      owner
      ...
      createdAt
      updatedAt
      __typename
    }
    ...
    createdAt
    updatedAt
    __typename
  }
}

Success! No errors.

{
  "data": {
    "getCompany": {
      "id": "49e8fddc-99d4-4997-88ac-76ee5baf806c",
      "owner": "a4c87468-3071-700a-0172-903242e45dc1",

      "centralInfrastructureId": null,
      "centralInfrastructure": null,
      "createdAt": "2024-06-28T14:42:22.833Z",
      "updatedAt": "2024-06-28T14:42:22.833Z",
      "__typename": "Company"
    }
  }
}

I can work around these new errors (though I'd rather not).
Is this suposed to be what happens? Create and Update resolvers return the same data as Get and List resolvers, but only the Create and Update resolvers return exceptions as well?

I also have similar schemas in different accounts (not exactly the same) and I haven't seen this behavior there.
Update resolvers don't throw exceptions on null nested @hasone objects in these different apps.

Expected behavior

Expect above CreateCompany mutation to not throw errors when nested @hasone object is null.

Reproduction steps

1. deploy a schema with a similar @hasone relationship as above
2. execute a Create mutation with a nested return object.

Project Identifier

d3r48sibna3q31

Log output

# Put your logs below this line

Additional information

No response

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.

[biller-aivy]

#2636

[DeezNutz2]

aws-amplify/amplify-category-api#2636

YES THANK YOU this is the same issue

[dpilch]

@aws-amplify/[email protected] has been released with a feature flag to opt-out of the new behavior.

Please see the updates to the following docs:

• https://docs.amplify.aws/gen1/javascript/build-a-backend/graphqlapi/subscribe-data/
• https://docs.amplify.aws/gen1/javascript/tools/cli/reference/feature-flags/#subscriptionsInheritPrimaryAuth.

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.