Aws-mobile-appsync-sdk-js: Missing field id in createPost mutation
Note: If your issue/feature-request/question is regarding the AWS AppSync service, please log it in the
official AWS AppSync forum
Do you want to request a feature or report a bug?
bug
What is the current behavior?
Calling the createPost mutation throws the following error
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.
Create post Mutation
Query list of posts
Decorator
What is the expected behavior?
The logic runs fine when adding the id field into the mutation.
Which versions and which environment (browser, react-native, nodejs) / OS are affected by this issue? Did this work in previous versions?
React Native
yhenni1989
All 3 comments
This is an expected behavior.
The issue here is that, during your mutation, you are providing a different 'structure' of the object that is defined on your query.
In your query you expect objects to have this structure.
{
id
name
}
however, what is being returned from your mutation and being written into the store is an object with this structure.
{
name
}
I am not sure if during the OptimisticResponse, your post object has the correct structure, but certainly when the second call of the update function is triggered with the server's response, The Apollo client writes into the store an object with an invalid structure.
So when you query the store after writing a single object, an error in types will rise, as the query is expecting all the objects to have an id attribute.
NeillGiraldo
on 30 Mar 2019
@jtaylor1989 - Does the response from @NeillGiraldo make sense?
haverchuck
on 15 Apr 2019
Yes it does.
yhenni1989
on 17 Apr 2019
Related issues
JonathanHolvey
路
4Comments
ArronHsiao
路
3Comments
fcobia
路
3Comments
wzup
路
3Comments
mwarger
路
3Comments
Most helpful comment
This is an expected behavior.
The issue here is that, during your mutation, you are providing a different 'structure' of the object that is defined on your query.
In your query you expect objects to have this structure.
{ id name }however, what is being returned from your mutation and being written into the store is an object with this structure.
{ name }I am not sure if during the OptimisticResponse, your post object has the correct structure, but certainly when the second call of the update function is triggered with the server's response, The Apollo client writes into the store an object with an invalid structure.
So when you query the store after writing a single object, an error in types will rise, as the query is expecting all the objects to have an id attribute.