Not all content types come back with space.getContentTypes()

We have a script that runs when we deploy our app to an environment in our build pipeline. I’m getting a bunch of 409 conflict errors when our automated space update happens.

Our update script calls space.getContentTypes() to get all the “remote” content types. It then looks at our local list bundled with the code and if the content type exists it updates it and publishes it. Otherwise it tries to create it.

The root cause of our issue is that when we run space.getContentTypes() it doesn’t return all of them. So our script tries to create a new content type in the target space. But it’s actually there in the space, so we get a 409.

I will create a ticket with Contentful so that I can list my actual space id and an example of a content type that doesn’t come back, but if there are any suggestions here that would be nice too.

Hi @dustin.aleksiuk,

Following up on this, because you’re not getting all the content types in your space, is it possible that the result set would exceed the default pagination limit of 100 elements?

Contentful uses the limit and skip parameters to manage pagination, a limit of 100 is used by default.

This means that if any of your responses contains more than 100 elements, they’d be truncated and you’d need to execute a second request with limit=100 and skip=100 in order to access the second page.

Alternatively, you could also simply a larger value for the limit parameter (e.g. limit=300).

Let me know if that could be the case or if you have any other questions.

1 Like

Yes, this is almost certainly the problem. I just checked the results and they are exactly 100. I’m going to look at one of your solutions right now.

Hi @gabriel,

I think we had two problems. One was what you described. We were hitting the 100 limit. The other was that we were updating our content types concurrently in our script and when I remove the concurrency to handle one at a time it started working consistently.

I think it’s likely that the issue was in our update script because I can’t imagine how your API wouldn’t handle many updates at once since from your perspective they are all separate PUT calls. Although maybe there’s some problem with the SDK not working properly with lots of concurrent calls.

Hi @dustin.aleksiuk,

I’m glad to hear that was able to help with this problem. As far as we know, the SDK doesn’t have any issues updating a particularly large amount of requests, but if you’re able to provide us with a bit more information sending an issue in our Github repo, we’d be glad to further investigate. :wink: