Strange AppSync errors (Amplify Gen 1)

The errors you're seeing are related to how AWS AppSync handles null values for fields that have non-nullable nested fields. When AWS AppSync is unable to process a request properly due to invalid data or syntax, it will return the field data with values set to null along with relevant errors.

In your case, the storageImage field itself is nullable in your schema, but the fields within the Storage type (bucket, key, contentType, lastModified, createdAt, updatedAt) are defined as non-nullable (required). When the parent field storageImage is null, AppSync is still trying to resolve its child fields, which are non-nullable, resulting in these errors.

This behavior might have been more lenient before, but it appears that AppSync is now more strictly enforcing the schema validation rules. This could be due to a recent update or change in how AppSync processes GraphQL responses.

To resolve this issue, you have a few options:

1. Make the fields within your Storage type nullable in your schema
2. Ensure that when storageImage is provided, all required fields within it are populated
3. Update your resolver to handle this case more gracefully

This type of error is common in GraphQL when dealing with nested objects that have required fields but the parent object is nullable.
Sources
Troubleshooting and common mistakes in AWS AppSync - AWS AppSync
ErrorDetail - AWS AppSync

In response to the AI answer...

The AppSync API is managed via Amplify so I can't go off piste and start modifying resolvers. I don't think making all fields nullable is an option and making sure all fields are populated wouldn't work as how does the caller know there will be an image available?

Remember that this is all done via Amplify Gen 1 with auto generated code. Why would AppSync try to resolve nested required fields if the parent is null?

✅ Problem:

Nullable parent type, but non-nullable children → AppSync now throws “Cannot return null for non-nullable type.”

💡 Cause:

AWS likely rolled out stricter schema validation in AppSync recently (enforcing GraphQL spec compliance).

💡 Fix:

Update schema: make child fields nullable if parent can be null. Example:

type Storage { bucket: String key: String contentType: String lastModified: String createdAt: AWSDateTime updatedAt: AWSDateTime }

Or use a resolver override to return an empty object with empty strings instead of null.

Thanks for the reply.

I can't make the child fields nullable as the primary key cannot be null.

The GraphQL spec says that if the parent is null then all sub items won't be resolved.

The current behavior doesn't seem right.

Hey Richard, AWS team,

we're experiencing the exact same issue with an Amplify Gen 1 / AppSync API. Mutations that include a nullable @belongsTo relationship (in our case, User.restaurant: Restaurant @belongsTo) are returning errors like: "Cannot return null for non-nullable type: 'ID' within parent 'Restaurant' (/updateUser/restaurant/id)" The restaurant field on User is nullable, but when it resolves to null, AppSync still attempts to resolve the nested id: ID! field on Restaurant, which then fails.

Key observations:

• Nothing changed on our side (schema, resolvers, or code)
• This started happening recently
• The GraphQL spec clearly states that if a parent field resolves to null, child fields should NOT be resolved
• This appears to be a stricter AppSync validation that breaks existing Amplify Gen 1 apps

Temporary mitigations we've explored that did not resolve the issue:

• Ensuring the foreign key (restaurantUsersId) is always populated when saving
• Removing the relationship field from selection sets when not needed
• Considering a separate nullable wrapper type

Has anyone found a proper fix or heard from AWS about this change? This seems like a breaking change for existing Amplify Gen 1 applications that relied on nullable relationships working correctly.