I like that you took the time to make a fresh post actually, I hope that anyone else looking for this finds it and shares their thoughts as well.
This has been a longstanding issue if I recall correctly, and one that we’ve spoken about before. I know I’ve logged this as an issue before and I’ll find it again and make some more noise to try to get attention on it again. It’s not an issue that I know of a solution to though and I would call this a bug.
Metafield webhooks technically exist, they’re just resource-specific and require adding metafield_namespaces to the payload sent when setting up a new webhook subscription. I would imagine just having a general webhook create/update webhook topic would result in a ton of noise and webhook traffic, most of which the clients consuming the webhooks wouldn’t find any value in - so I’m not sure creating a new topic would be the ideal solution here. I’d prefer we just fixed the bug and mde sure that the behaviour was consistent across every resource.
We need reports to load reasonably fast and the only way to do that is to keep the metafields in sync locally.
Even with the graph bulk metafield loading capabilities, reports that aggregate a lot of data would still need to make many calls and it would cause reports to load very slowly, if at all.
Fair enough - I just think that the vast majority of webhooks I’ve seen wouldn’t be relevant to third-parties, but I can understand after filtering out the excess noise how this might be useful. I’d somewhat prefer to have the root issue of the update behaviour being inconsistent resolved first, but I’ll file a request for a new webhook as well.
A separate topic would be mean that only apps interested in metafields would subscribe, which should remove the noise issue which is present today (for orders and products at least).
Thanks for that Josh. I hope the request gets traction!