How to Get Rid of Error Fetching Config on a PWA eCommerce Site

Finding a bug and fixing it on an eCommerce website that is already live is one one the main recurring tasks for a support dev team. Some bugs are not that hard to find, but what makes the situation tricky is that, in eCommerce, one tiny bug can literally lead to revenue losses. So being swift at tackling issues on live eCom websites is the key. Here’s a good example of fixing a tiny, yet disturbing bug illustrated by Scandiweb’s practical experience with Magento/Adobe Commerce eCom websites. 

Sometimes during development, some features are no longer needed. What a dev is supposed to do? The most logical decision is to remove it. And if it involves some GraphQL data, a developer would also need to clean some stuff up. 

So, you need to

• remove relevant BE code,
• remove old entries in schema.graphql,
• and remove all references of those entries in *.query.js files.

The thing is that you will get an error on the site – Error fetching config. So why this error occurs on a busy live site? 

The problem is that some user has the old queries cached in their browsers. If a user does a request first, the old query will be cached in our servers for everyone – that is why we get an error that does not go away that simple.

Here’s how the initial config in the schema.graphql looks like

type StoreConfig {
    clerk_use_clerk: Boolean @doc(description: "Use clerk sliders")
    clerk_public_key: String @doc(description: "Clerk public key")
}
and in Config.query.js we would have the following:
   getConfigQuery() {
        return new Field('storeConfig')
            .addFieldList([
                'header_logo_src',
                'default_display_currency_code',
                'clerk_use_clerk',
                'clerk_public_key'
            ]);
    }

So, let’s imagine we want to extend Clerk config parameters and move them to a dedicated clerk subsection in the config.

The first step would be to remove them from the Config.query.js but keep them in the schema.graphql. We clean them out from the BE configs only later. 

The updated schema.graphql would look like this.

type StoreConfig {
    clerk_use_clerk: Boolean @doc(description: "Deprecated, to be removed")
    clerk_public_key: String @doc(description: "Deprecated, to be removed")
    clerk: ClerkConfig @resolver(class: "Magento\\StoreGraphQl\\Model\\Resolver\\StoreConfigResolver")
}

type ClerkConfig {
    use_clerk: Boolean @doc(description: "Use clerk sliders")
    public_key: String @doc(description: "Clerk public key")
    merchandising_id: String @doc(description: "Clerk Merchandising ID")
}
and the Config.query.js  would look like this
   getConfigQuery() {
        return new Field('storeConfig')
            .addFieldList([
                'header_logo_src',
                'default_display_currency_code',
                this._getClerkConfigurationFields()
            ]);
    }

    _getClerkConfigurationFields() {
        return new Field('clerk')
            .addFieldList([
                'use_clerk',
                'public_key',
                'merchandising_id'
            ]);
    }

As a result, the users will get a new config structure with this deployment but BE structure and support for the older deprecated config structure will be retained until the next deployment. 

After a successful deployment of the changes, we can remove deprecated config keys from the BE and deploy those in a few days when cached versions of the config will have been updated. 

So, the final version of schema.graphql would look like this. Remember, deploy sometime later.

type StoreConfig {
    clerk: ClerkConfig @resolver(class: "Magento\\StoreGraphQl\\Model\\Resolver\\StoreConfigResolver")
}

type ClerkConfig {
    use_clerk: Boolean @doc(description: "Use clerk sliders")
    public_key: String @doc(description: "Clerk public key")
    merchandising_id: String @doc(description: "Clerk Merchandising ID")
}

Hope this trick will help you with your eCommerce projects!

Are you experiencing issues with your Magento (Adobe) eCommerce store? Our team of certified Magento Developers can help. Scandiweb is the most certified Magento team in the world with 230+ Magento-certified developers and solution specialists. Tell us about your issue here.

Share on: