amplify-cli: Subscription returns null for deep elements. (And with mock it works perfectly) amplify graphql
Hi everyone, I’m currently using subscriptions to update the state of my “manager” in order to spread the update through useContext.
The problem I encountered is that when I enter in the subscription, I update my manager data with the subscription response. But I had issues because the response was incomplete. Some attributes were returned as null even if they existed.
I don’t have the issue when I use the mock. That’s why i’m suruprised. I thought maybe it’s due to aync stuff, but I don’t get how the subscription can return data if it didn’t retrieve all the data I asked for.
Anyway, here is some of my code : My graphql schema table :
type Manager @model
@auth(rules: [
{allow: owner},
{allow: groups, groups: ["Admin"]}
{allow: public, operations: [read], provider: apiKey}
])
{
id: ID!
email: String!
name: String!
surname: String!
phone: String!
shops: [Shop] @connection(keyName: "byManager", fields: ["id"])
}
You can see each manager can have many shops. Here is the subscription code that is supposed to retrieve me some data
export const onDeleteShop = /* GraphQL */ `
subscription OnDeleteShop {
onDeleteShop {
id
manager {
id
email
name
surname
phone
createdAt
updatedAt
owner
shops {
items {
id
category
city
}
}
}
}
}
`;
And here is the code of my subcription :
return API.graphql(graphqlOperation(onDeleteShop, { owner: user.attributes.sub })).subscribe({
next: async (data) => {
console.log("on rentre dans la onDeleteShop souscription")
console.log(data.value.data.onDeleteShop)
setManager(data.value.data.onDeleteShop.manager)
}
})
I’m very surprised that it’ working perfectly when I use the mock, and when I’m in normal mode it returns me null for shops :
{id: "xxx-xxx-xxx-xxx", manager: {…}}
id: "xxx-xxx-xxx-xxx"
manager:
createdAt: "2021-01-15T12:13:53.288Z"
email: ""
id: "xxx-xxx-xxx-xxx"
name: "V"
owner: "xxx-xxx-xxx-xxx"
phone: ""
shops: null
surname: "W"
updatedAt: "2021-01-15T12:13:53.288Z"
__proto__: Object
__proto__: Object
If instead of updating my manager state with the subscription returned data like this
setManager(await data.value.data.onCreateShop.manager)
I call the getManager Query, everything works. But I don’t get why my subscription data is not fully loaded.
To solve my issue i called inside the subscription a query to get all my manager data :
setManager(API.graphql(graphqlOperation(listManagers))
I hope you understand me.
I use amplify 4.41.2 on MacOS
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 15 (4 by maintainers)
Make sure the mutation that fires the subscription retrieves the data you expect from the subscription. Subscriptions are only filtering the data retrieved by the mutation, it’s not getting any data from the database.
@vincent38wargnier It’s not clear to me if you found a solution to your issue or a workaround? I have the same issue, am using the auto-generated subscriptions with depth 3, but I still get null for the connection elements just like your original question.
Edit: nevermind, just figured it out. I agree with you that it is not intuitive that your mutation must return the info that you want the subscription to also return. For those reading after this, some clarification: If you want your subscription to return your @connection info, those connected fields also need to be part of your mutation. If your subscription is depth 3, your mutation must also be depth 3. You must also include all of the required (“!”) fields in your mutation, or you will get a null error with the subscription.
Yes that’s what I understood. But this behaviour is not very instinctive, neither convenient. And then there is a bug in the mock, because the mock subscriptions retrieve all the data we ask for whatever data is triggered by the mutation that fires the subscription. (This mock behaviour is more instinctive I think, that’s why it’s even more complicated to understand how to use subscriptions in production)
Hi @vincent38wargnier. We’re aware of this issue and are working with the service team to investigate it.