v6: InvalidWebhookError: No HTTP webhooks registered for topic products/update

[mariusa]

Issue summary

Trying to migrate from v5 to v6. Updated code as per guide.

Webhooks are registered for topics such as PRODUCTS_UPDATE
but shopify.webhooks.process() gives
InvalidWebhookError: No HTTP webhooks registered for topic products/update

Looks like products/update got forgotten to be handled as PRODUCTS_UPDATE internally?

If we do the registration wrong, at least the error message should reference to correct topic.

Checklist

• I have described this issue in a way that is actionable (if possible)

[paulomarg]

Hi again! This error is thrown when the library can't find the handler to call for a specific topic, as you mentioned. Just to make sure the set up is correct here, are you adding a handler for that topic, as per https://github.com/Shopify/shopify-api-js/blob/main/docs/migrating-to-v6.md#changes-to-webhook-functions?

I assume your call looks like this?

await shopify.webhooks.addHandlers({
  PRODUCTS_UPDATE: {
    deliveryMethod: DeliveryMethod.Http,
    callbackUrl: shopify.config.webhooks.path,
    callback: () => { /* ... */ },
  },
});

If we do the registration wrong, at least the error message should reference to correct topic.

That makes sense. products/update is the format Shopify passes the topic in, but we do translate it to PRODUCTS_UPDATE internally to match the GraphQL API. We should log the translated topic here.

[mariusa]

Hi & thanks,

are you adding a handler for that topic,

Yes, when the app starts, similar to your code example
shopify.config.webhooks.path doesn't exist, so using

let handlers2 = {
        PRODUCTS_UPDATE: {
            deliveryMethod: 'http',
            callbackUrl: `https://pastebin.com`,
            callback: () => { console.log('test PRODUCTS_UPDATE') },
        }
    }

    console.log('handlers2', handlers2)
    await shopify.webhooks.addHandlers(handlers2)
    const topicsAdded = shopify.webhooks.getTopicsAdded()
    console.log('topicsAdded', topicsAdded)

gives

handlers2 {
  PRODUCTS_UPDATE: {
    deliveryMethod: 'http',
    callbackUrl: 'https://pastebin.com',
    callback: [Function: callback]
  }
}
topicsAdded [ 'PRODUCTS_UPDATE' ]

Note that these webhooks are created with v5 and show properly when listed.
¯_(ツ)_/¯

[mariusa]

Ok, it turns out that handler.callbackUrl !== request.url, one has the hostname, the other doesn't. I'll figure out why.

Having a log.warning here, for each condition in turn when it doesn't match, would have helped:

shopify-api-js/lib/webhooks/process.ts

Line 62 in 0d19fe2

handler.callbackUrl !== request.url

[mariusa]

Hmm, don't know how to solve this. I'm using Fastify, calling process() like this:

await shopify.webhooks.process({
                    rawBody: req.rawBody,
                    rawRequest: req.raw,
                    rawResponse: reply.raw,
                })

req.raw.url is relative, it does NOT include hostname. I can't change that.

Even if it would include a host a hostname, might not the same as handler.callbackUrl or
shopify.config.hostName, eg localhost vs ngrok, or different hostnames for oauth and webhook processing, or having a proxy in front of many webhook processing servers (with different hostnames).

I think URLs or even delivery methods shouldn't be compared. Just process the webhook, please , as in v5.

[paulomarg]

That's a fair point - we shouldn't consider the hostname in the comparison, and instead just check the paths here.

[mariusa]

I've updated my comment:

Even if it would include a host a hostname, might not the same as handler.callbackUrl or
shopify.config.hostName, eg localhost vs ngrok, or different hostnames for oauth and webhook processing, or having a proxy in front of many webhook processing servers (with different hostnames).

I think URLs or even delivery methods shouldn't be compared. Just process the webhook, please , as in v5.

Just comparing paths won't work either, as our development has a webhook processing service with a random path, which forwards to localhost/fixed/path.
I'm sure there are some valid production cases where paths could differ too, eg proxy in front.

[mariusa]

Thanks Paulo! Looking forward to next release :)