409 Conflict error when Importing

We have a script that applies the content model to a target space as part of our automated build pipeline. The script loops through all the content types and applies them one by one (each content type is stored as a separate file in git). We’re getting a new error on certain content types: 409 Conflict, which is a apparently a version mismatch.

To debug this, I exported our production space into a brand new empty space and tried to update the content model. I even got 409 Conflict errors on this import which is weird because I imported into an empty space. I shouldn’t get version mismatch importing into an empty space.

I looked it up on Contentful’s error page and it says this for 409: “This error occurs when you’re trying to update an existing asset, entry or content type, and you didn’t specify the current version of the object or specified an outdated version.”

Applying the content model works when I apply it to our TEST environment. I get these 409s when I apply it to our PRE environment. I compared the content types in the error message and I can’t see a difference.

Any thoughts on how I can debug this further?

Hi @dustin.aleksiuk,

Could you clarify if you’re simply using the import/export tools, or if you’re also using custom scripts? Also, what version of the tools are you using?

HI @gabriel ,

I combined a couple of things during my investigation so it is a bit confusing.

There are two aspects:

We are using custom scripts to promote the content model from a lower environment to a higher one (ie. PRE to PROD). Those are failing with 409 errors. This is the fundamental issue I’m trying to solve.

In order to debug the above issue, I used the export and import tools to make a copy of our production space. I got 409 errors (and some other validation errors that are obviously our fault). These 409 errors seem really weird to me because it was an import into a brand new empty space. So how could I have version conflicts?

Thanks very much for your response. I can create a ticket for Contentful support too.

Edit: I forgot to mention - I’m using the latest version of the tools. I reinstalled them just for this project.

contentful-export@6.0.4
contentful-import@6.2.3

It’s not very common to receive 409 errors in the export/import tools, and it might be the case this an issue affecting entries directly under our API.

It’d be great if you could open a support ticket with us in this page and provide us the commands and relevant parts of the script you’re using. :slight_smile:

Hi @gabriel ,

I opened a ticket but my second issue of the plain export/import wasn’t reproducible.

Would you mind elaborating a bit on how versions work with content types? Is the basic issue that we’re trying to apply an older version of a content type to a newer version? This is from the Contentful docs:

This error occurs when you’re trying to update an existing asset, entry or content type, and you didn’t specify the current version of the object or specified an outdated version.

Thanks,
Dustin

Absolutely, @dustin.aleksiuk, and you can also find a nice reference about versioning here.

Our content type, like entries, allow versioning, which points to recorded versions every time you change your content type.

However, unlike entries, you cannot actually inspect these versions through the Web Interface. Instead, you’d have to do so by using our APIs and SDKs.

When updating a content type, the API requires that you send the header property X-Contentful-Version in your request, specifying the last version of the content type that is about to be updated.

In order to see what’s the current version of the content type, you can use the Content Management API and do a GET request for the same entry and take the value of the sys.version JSON property.

With that, you should be able to update your content type without any issues.

Let me know if that makes sense or if you have any other questions. :smile:

I really appreciate that response.

We’re using the Javascript SDK to update content types. We store our content types as individual files in version control and loop through them and update them.

We are not specifying a version number when we do this. Things started breaking for us on March 12th. Do you have any idea why things might have starting going wrong around that time? And do you know what the default behaviour is for the SDK?

Update: I see something odd going on when we query the space for the content types. I think this version number thing is a red herring. I’m going to write up a new thread for this since it’s a new topic.

Hi @dustin.aleksiuk,

It’d be indeed a better idea to start a new thread and I’ll let our JS SDK engineers aware if it does indeed have a bug.

Thanks @gabriel, I created this thread: