fix: avoid errors when excluding content types with multiple sources … #246

ccarrascal · 2025-05-27T14:40:41Z

…using the same schema

PR to fix errors happening while building a site importing content from two different stacks.

Our schema is the same in both stacks and we just want to combine the content of both, but we need to exclude some content types from the shared stack that we don't want to import.

We are using this setup in our gatsby-config file:

// Shared content stack
{
    resolve: "gatsby-source-contentstack",
    options: {
        api_key: process.env.SHARED_CONTENTSTACK_API_KEY,
        delivery_token: process.env.SHARED_CONTENTSTACK_DELIVERY_TOKEN,
        environment: process.env.GATSBY_CONTENTSTACK_ENVIRONMENT,
        cdn: "https://eu-cdn.contentstack.com/v3",
        disableMandatoryFields: "true",
        downloadImages: "false",
        ...{ locales: process.env.GATSBY_LOCALES?.split(",").map((s) => s.trim()) },
        excludeContentTypes: ["shell"],
    },
},
// Primary content stack
{
    resolve: "gatsby-source-contentstack",
    options: {
        api_key: process.env.CONTENTSTACK_API_KEY,
        delivery_token: process.env.CONTENTSTACK_DELIVERY_TOKEN,
        environment: process.env.GATSBY_CONTENTSTACK_ENVIRONMENT,
        cdn: "https://eu-cdn.contentstack.com/v3",
        enableSchemaGeneration: "true",
        disableMandatoryFields: "true",
        downloadImages: "false",
        ...{ locales: process.env.GATSBY_LOCALES?.split(",").map((s) => s.trim()) },
    },
},

The first instance (shared content) is excluding some content types with excludeContentTypes: ["shell"]

This is creating errors as the contentType variable is empty because there is no match in contentTypesMap[item.content_type_uid]

The idea is to avoid creating the node if the content type uid is in the list of excluded content types, or it just null.

Staging->main

abhishek305

@ccarrascal Thanks for the update! Please verify the suggested feedback—everything else looks good to me.
Once approved, we’ll proceed to merge the changes into staging and validate the functionality there.

src/source-node.js

…using the same schema

abhishek305 · 2025-06-27T15:13:58Z

@ccarrascal Just revisiting the issue for clarity—while testing the changes, could you please share the exact error you were encountering during node generation? It would help in documenting and validating the fix better.

Could you also help me with the steps to reproduce ?
As I am currently trying to reproduce the issue with the below config, where I am excluding the "footer" content-type with the PR changes still the build is breaking.

      resolve: "gatsby-source-contentstack",
      options: {
        api_key: CONTENTSTACK_API_KEY,
        delivery_token: CONTENTSTACK_DELIVERY_TOKEN,
        environment: CONTENTSTACK_ENVIRONMENT,
        branch: CONTENTSTACK_BRANCH ? CONTENTSTACK_BRANCH : "main",
        cdn: `https://cdn.contentstack.io/v3`,
        // Specify whether to convert RTE Json to HTML
        jsonRteToHtml: true,
        // Optional: expediteBuild set this to either true or false
        expediteBuild: true,
        // Optional: Specify true if you want to generate custom schema
        enableSchemaGeneration: true,
        // Optional: Specify a different prefix for types. This is useful in cases where you have multiple instances of the plugin to be connected to different stacks.
        type_prefix: "Contentstack", // (default),
        excludeContentTypes: ["footer"],
      },
    },
    {
      resolve: "gatsby-source-contentstack",
      options: {
        api_key: "key",
        delivery_token: "delivery key",
        environment: "preview",
        branch: CONTENTSTACK_BRANCH ? CONTENTSTACK_BRANCH : "main",
        cdn: `https://cdn.contentstack.io/v3`,
        // Specify whether to convert RTE Json to HTML
        jsonRteToHtml: true,
        // Optional: expediteBuild set this to either true or false
        expediteBuild: true,
        // Optional: Specify true if you want to generate custom schema
        enableSchemaGeneration: true,
        // Optional: Specify a different prefix for types. This is useful in cases where you have multiple instances of the plugin to be connected to different stacks.
        type_prefix: "Contentstack_v2", // (default),
      },
    },

abhishek305 · 2025-07-02T13:31:33Z

@ccarrascal Just revisiting the issue for clarity—while testing the changes, could you please share the exact error you were encountering during node generation? It would help in documenting and validating the fix better.

Could you also help me with the steps to reproduce ? As I am currently trying to reproduce the issue with the below config, where I am excluding the "footer" content-type with the PR changes still the build is breaking.

      resolve: "gatsby-source-contentstack",
      options: {
        api_key: CONTENTSTACK_API_KEY,
        delivery_token: CONTENTSTACK_DELIVERY_TOKEN,
        environment: CONTENTSTACK_ENVIRONMENT,
        branch: CONTENTSTACK_BRANCH ? CONTENTSTACK_BRANCH : "main",
        cdn: `https://cdn.contentstack.io/v3`,
        // Specify whether to convert RTE Json to HTML
        jsonRteToHtml: true,
        // Optional: expediteBuild set this to either true or false
        expediteBuild: true,
        // Optional: Specify true if you want to generate custom schema
        enableSchemaGeneration: true,
        // Optional: Specify a different prefix for types. This is useful in cases where you have multiple instances of the plugin to be connected to different stacks.
        type_prefix: "Contentstack", // (default),
        excludeContentTypes: ["footer"],
      },
    },
    {
      resolve: "gatsby-source-contentstack",
      options: {
        api_key: "key",
        delivery_token: "delivery key",
        environment: "preview",
        branch: CONTENTSTACK_BRANCH ? CONTENTSTACK_BRANCH : "main",
        cdn: `https://cdn.contentstack.io/v3`,
        // Specify whether to convert RTE Json to HTML
        jsonRteToHtml: true,
        // Optional: expediteBuild set this to either true or false
        expediteBuild: true,
        // Optional: Specify true if you want to generate custom schema
        enableSchemaGeneration: true,
        // Optional: Specify a different prefix for types. This is useful in cases where you have multiple instances of the plugin to be connected to different stacks.
        type_prefix: "Contentstack_v2", // (default),
      },
    },

@ccarrascal could you please provide me with an update here?

ccarrascal · 2025-07-04T11:10:47Z

@ccarrascal Just revisiting the issue for clarity—while testing the changes, could you please share the exact error you were encountering during node generation? It would help in documenting and validating the fix better.
Could you also help me with the steps to reproduce ? As I am currently trying to reproduce the issue with the below config, where I am excluding the "footer" content-type with the PR changes still the build is breaking.

      resolve: "gatsby-source-contentstack",
      options: {
        api_key: CONTENTSTACK_API_KEY,
        delivery_token: CONTENTSTACK_DELIVERY_TOKEN,
        environment: CONTENTSTACK_ENVIRONMENT,
        branch: CONTENTSTACK_BRANCH ? CONTENTSTACK_BRANCH : "main",
        cdn: `https://cdn.contentstack.io/v3`,
        // Specify whether to convert RTE Json to HTML
        jsonRteToHtml: true,
        // Optional: expediteBuild set this to either true or false
        expediteBuild: true,
        // Optional: Specify true if you want to generate custom schema
        enableSchemaGeneration: true,
        // Optional: Specify a different prefix for types. This is useful in cases where you have multiple instances of the plugin to be connected to different stacks.
        type_prefix: "Contentstack", // (default),
        excludeContentTypes: ["footer"],
      },
    },
    {
      resolve: "gatsby-source-contentstack",
      options: {
        api_key: "key",
        delivery_token: "delivery key",
        environment: "preview",
        branch: CONTENTSTACK_BRANCH ? CONTENTSTACK_BRANCH : "main",
        cdn: `https://cdn.contentstack.io/v3`,
        // Specify whether to convert RTE Json to HTML
        jsonRteToHtml: true,
        // Optional: expediteBuild set this to either true or false
        expediteBuild: true,
        // Optional: Specify true if you want to generate custom schema
        enableSchemaGeneration: true,
        // Optional: Specify a different prefix for types. This is useful in cases where you have multiple instances of the plugin to be connected to different stacks.
        type_prefix: "Contentstack_v2", // (default),
      },
    },

@ccarrascal could you please provide me with an update here?

Hi there, sorry for the late reply, I have been out for some days.

This is very weird. I am testing it again and now I can't reproduce the error anymore.
The original error was here:

https://github.com/contentstack/gatsby-source-contentstack/blob/master/src/normalize.js#L61

It was because contentType variable was null, and so contentType.schema failed with an error. That's why I introduced the check in source-node.js file to avoid calling normalizeEntry with a null value, but as I say, I can't reproduce it anymore.

I still think it's good idea to introduce that check just in case, but I am a bit puzzled.

What's the error that you are getting? I see that you are using a different type_prefix config parameter there, and I am not, cause the prefix change will make our content queries to fail.

abhishek305 · 2025-07-06T08:11:06Z

@ccarrascal Just revisiting the issue for clarity—while testing the changes, could you please share the exact error you were encountering during node generation? It would help in documenting and validating the fix better.
Could you also help me with the steps to reproduce ? As I am currently trying to reproduce the issue with the below config, where I am excluding the "footer" content-type with the PR changes still the build is breaking.
      resolve: "gatsby-source-contentstack",
      options: {
        api_key: CONTENTSTACK_API_KEY,
        delivery_token: CONTENTSTACK_DELIVERY_TOKEN,
        environment: CONTENTSTACK_ENVIRONMENT,
        branch: CONTENTSTACK_BRANCH ? CONTENTSTACK_BRANCH : "main",
        cdn: `https://cdn.contentstack.io/v3`,
        // Specify whether to convert RTE Json to HTML
        jsonRteToHtml: true,
        // Optional: expediteBuild set this to either true or false
        expediteBuild: true,
        // Optional: Specify true if you want to generate custom schema
        enableSchemaGeneration: true,
        // Optional: Specify a different prefix for types. This is useful in cases where you have multiple instances of the plugin to be connected to different stacks.
        type_prefix: "Contentstack", // (default),
        excludeContentTypes: ["footer"],
      },
    },
    {
      resolve: "gatsby-source-contentstack",
      options: {
        api_key: "key",
        delivery_token: "delivery key",
        environment: "preview",
        branch: CONTENTSTACK_BRANCH ? CONTENTSTACK_BRANCH : "main",
        cdn: `https://cdn.contentstack.io/v3`,
        // Specify whether to convert RTE Json to HTML
        jsonRteToHtml: true,
        // Optional: expediteBuild set this to either true or false
        expediteBuild: true,
        // Optional: Specify true if you want to generate custom schema
        enableSchemaGeneration: true,
        // Optional: Specify a different prefix for types. This is useful in cases where you have multiple instances of the plugin to be connected to different stacks.
        type_prefix: "Contentstack_v2", // (default),
      },
    },
@ccarrascal could you please provide me with an update here?
Hi there, sorry for the late reply, I have been out for some days.

This is very weird. I am testing it again and now I can't reproduce the error anymore. The original error was here:

https://github.com/contentstack/gatsby-source-contentstack/blob/master/src/normalize.js#L61

It was because contentType variable was null, and so contentType.schema failed with an error. That's why I introduced the check in source-node.js file to avoid calling normalizeEntry with a null value, but as I say, I can't reproduce it anymore.

I still think it's good idea to introduce that check just in case, but I am a bit puzzled.

What's the error that you are getting? I see that you are using a different type_prefix config parameter there, and I am not, cause the prefix change will make our content queries to fail.

Thanks for the update, @ccarrascal

I wasn’t able to reproduce the issue on my end either — that’s why I was hoping to get the exact error message or a screenshot from your side, just to confirm the scenario.

Also, could you please confirm if you’re using the same type_prefix in both your config and your GraphQL content queries? Just want to rule out any mismatches there.

If possible, it would be great if you could try reproducing the issue once more. This would help us validate the necessity of the null check and move forward with the PR.

Appreciate your help!

ccarrascal · 2025-07-07T11:54:54Z

@ccarrascal Just revisiting the issue for clarity—while testing the changes, could you please share the exact error you were encountering during node generation? It would help in documenting and validating the fix better.
Could you also help me with the steps to reproduce ? As I am currently trying to reproduce the issue with the below config, where I am excluding the "footer" content-type with the PR changes still the build is breaking.
      resolve: "gatsby-source-contentstack",
      options: {
        api_key: CONTENTSTACK_API_KEY,
        delivery_token: CONTENTSTACK_DELIVERY_TOKEN,
        environment: CONTENTSTACK_ENVIRONMENT,
        branch: CONTENTSTACK_BRANCH ? CONTENTSTACK_BRANCH : "main",
        cdn: `https://cdn.contentstack.io/v3`,
        // Specify whether to convert RTE Json to HTML
        jsonRteToHtml: true,
        // Optional: expediteBuild set this to either true or false
        expediteBuild: true,
        // Optional: Specify true if you want to generate custom schema
        enableSchemaGeneration: true,
        // Optional: Specify a different prefix for types. This is useful in cases where you have multiple instances of the plugin to be connected to different stacks.
        type_prefix: "Contentstack", // (default),
        excludeContentTypes: ["footer"],
      },
    },
    {
      resolve: "gatsby-source-contentstack",
      options: {
        api_key: "key",
        delivery_token: "delivery key",
        environment: "preview",
        branch: CONTENTSTACK_BRANCH ? CONTENTSTACK_BRANCH : "main",
        cdn: `https://cdn.contentstack.io/v3`,
        // Specify whether to convert RTE Json to HTML
        jsonRteToHtml: true,
        // Optional: expediteBuild set this to either true or false
        expediteBuild: true,
        // Optional: Specify true if you want to generate custom schema
        enableSchemaGeneration: true,
        // Optional: Specify a different prefix for types. This is useful in cases where you have multiple instances of the plugin to be connected to different stacks.
        type_prefix: "Contentstack_v2", // (default),
      },
    },
@ccarrascal could you please provide me with an update here?
Hi there, sorry for the late reply, I have been out for some days.
This is very weird. I am testing it again and now I can't reproduce the error anymore. The original error was here:
https://github.com/contentstack/gatsby-source-contentstack/blob/master/src/normalize.js#L61
It was because contentType variable was null, and so contentType.schema failed with an error. That's why I introduced the check in source-node.js file to avoid calling normalizeEntry with a null value, but as I say, I can't reproduce it anymore.
I still think it's good idea to introduce that check just in case, but I am a bit puzzled.
What's the error that you are getting? I see that you are using a different type_prefix config parameter there, and I am not, cause the prefix change will make our content queries to fail.
Thanks for the update, @ccarrascal

I wasn’t able to reproduce the issue on my end either — that’s why I was hoping to get the exact error message or a screenshot from your side, just to confirm the scenario.

Also, could you please confirm if you’re using the same type_prefix in both your config and your GraphQL content queries? Just want to rule out any mismatches there.

If possible, it would be great if you could try reproducing the issue once more. This would help us validate the necessity of the null check and move forward with the PR.

Appreciate your help!

Hi @abhishek305

I have been checking with other developers in our team to see if they can reproduce the problem, but we couldn't.
Our builds are working fine now without these changes. Both yarn start and yarn build works properly now.

Regarding the type_prefix, I can confirm we are using the same for both config, we can't really change that, as it will break our queries and we'll have to rewrite them, and that was what we were trying to avoid in the first place by just ignoring some content types.

So from our side, it works now, so there's no need to merge this PR anymore apparently. I still don't know why it works now, maybe some recent changes in the CS API?

I'll let you decide if you want to merge it in or not, cause it does not look like we need it anymore.

Thanks a lot for your support in this issue.

Best regards

abhishek305 · 2025-07-07T12:19:42Z

Hi @abhishek305

I have been checking with other developers in our team to see if they can reproduce the problem, but we couldn't. Our builds are working fine now without these changes. Both yarn start and yarn build works properly now.

Regarding the type_prefix, I can confirm we are using the same for both config, we can't really change that, as it will break our queries and we'll have to rewrite them, and that was what we were trying to avoid in the first place by just ignoring some content types.

So from our side, it works now, so there's no need to merge this PR anymore apparently. I still don't know why it works now, maybe some recent changes in the CS API?

I'll let you decide if you want to merge it in or not, cause it does not look like we need it anymore.

Thanks a lot for your support in this issue.

Best regards

Thanks for the confirmation, Carlos!

Since the issue is no longer reproducible and everything is working fine on your end — including consistent type_prefix usage and successful builds — I’ll go ahead and close this PR and the related ticket.

Appreciate your follow-up and the detailed checks you did with your team. If the issue resurfaces, feel free to reach out and we can revisit the fix.

Thanks again!

Best regards,
Abhishek

cc @PriteshJain

Contentstack-AnkitaD and others added 13 commits March 27, 2025 15:12

Merge pull request contentstack#245 from contentstack/staging

f4f238a

Staging->main

policy-scan.yml

8840818

issues-jira.yml

41e2233

Delete jira.yml

66350a0

Delete sast-scan.yml

43ad4fd

codeql-analysis.yml

dcf36d6

Updated codeowners

a6c7e4a

policy-scan.yml

28617d8

policy-scan.yml

619907e

issues-jira.yml

aac76e3

secrets-scan.yml

7780349

talismanrc file updated

412540b

Updated codeowners

8e90682

ccarrascal requested a review from a team as a code owner May 27, 2025 14:40

abhishek305 changed the base branch from master to staging June 23, 2025 14:27

abhishek305 reviewed Jun 23, 2025

View reviewed changes

src/source-node.js Outdated Show resolved Hide resolved

fix: avoid errors when excluding content types with multiple sources …

373c43b

…using the same schema

ccarrascal force-pushed the fix/errors-with-excluded-content-types branch from be3011f to 373c43b Compare June 23, 2025 16:40

abhishek305 approved these changes Jun 24, 2025

View reviewed changes

abhishek305 mentioned this pull request Jun 27, 2025

fix: avoid errors when excluding content types with multiple sources #247

Closed

abhishek305 closed this Jul 7, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix: avoid errors when excluding content types with multiple sources … #246

fix: avoid errors when excluding content types with multiple sources … #246

ccarrascal commented May 27, 2025

Uh oh!

abhishek305 left a comment

Uh oh!

Uh oh!

abhishek305 commented Jun 27, 2025 •

edited

Loading

Uh oh!

abhishek305 commented Jul 2, 2025

Uh oh!

ccarrascal commented Jul 4, 2025

Uh oh!

abhishek305 commented Jul 6, 2025 •

edited

Loading

Uh oh!

ccarrascal commented Jul 7, 2025

Uh oh!

abhishek305 commented Jul 7, 2025

Uh oh!

Uh oh!

fix: avoid errors when excluding content types with multiple sources … #246

fix: avoid errors when excluding content types with multiple sources … #246

Conversation

ccarrascal commented May 27, 2025

Uh oh!

abhishek305 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

abhishek305 commented Jun 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

abhishek305 commented Jul 2, 2025

Uh oh!

ccarrascal commented Jul 4, 2025

Uh oh!

abhishek305 commented Jul 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ccarrascal commented Jul 7, 2025

Uh oh!

abhishek305 commented Jul 7, 2025

Uh oh!

Uh oh!

abhishek305 commented Jun 27, 2025 •

edited

Loading

abhishek305 commented Jul 6, 2025 •

edited

Loading