According to the docs here:
You can perform deep mutations at multiple levels. Deep mutations do not alter linked objects, but they can add deeply-nested new objects …
Since deep mutations can add new objects, shouldn’t it trigger my registered add-webhook on the nested object? But this is not the case for me.
@abhimanyusinghgaur, is this the expected behaviour?
No. For example, if you have a schema like:
type Author @lambdaOnMutate(add: true) {
...
posts: [Post]
}
type Post @lambdaOnMutate(add: true) {
...
author: Author @hasInverse(field: posts)
}
and you are doing an addAuthor with nested posts, then the webhook registered for Author.add will be triggered, not the one on Post.add. The Author.add webhook will get an event that contains the input that addAuthor received, including the nested posts.
If Author.add isn’t getting triggered, then it might be a bug.
oh 
That would not be as I expected it either then.
Use Case Scenario, I want to run a spellcheck webhook every time a new post is added. A new post can be added when adding a new tag, new category, new user, new comment, etc. So I have to then create the same webhook for every single parent object and look for deeply nested data and run the correct webhook. That is not what I was expecting this does. I (and at least another user) expected that this ran the webhook for whenever that data is added.
But, I guess that makes sense, the webhook is tied directly to the generated mutation (lambdaOnMutate), not the type as it appears in the schema. Just more extra steps to get what we need then.
The main problem here is schema scale. I setup up webhooks and then scale my schema adding more types that can create new posts as their children and forget to add the webhooks for those mutations watching for children and running my existing webhooks, then it easily becomes something that I just don’t do. I hope this can be expanded to cover the use case presented to run everytime the type is added not just the add mutation is ran for that specific type that has the webhook.
While this is the current behaviour, I believe it’s much more scalable and useful to trigger separate webhooks per type (in other words, this is a feature request). Given the flexibility of graph queries/mutations, queries can be non-deterministic especially for complex graphs. Using the example you gave, the Author can be created by deeply nesting with Post and vice-versa. In which case, the API implementation must handle webhooks for all possible options—and therefore becoming impractical—for creating either an Author or Post instead of once on the type.
@abhimanyusinghgaur is this something that can be considered as a feature request?
@abhimanyusinghgaur Hope you’re well. I’m now implementing a workaround pending this enhancement. Any ETA at the moment?
+1 for this feature request.
It’s rather odd (and inefficient) that you currently would have to implement a webhook resolver for every parent that contains the object of interest as a child.