We've experience an issue twice after deploy, where a new PageType won't get registred in the database correctly.
It is listed inside the Admin/Content Types interface, but if we try to create a page we get the following database error.
The INSERT statement conflicted with the FOREIGN KEY constraint "FK_tblContent_tblContentType". The conflict occurred in database "Website_V2", table "dbo.tblContentType", column 'pkID'.
To fix the issue we've had to restart the two instances on our App Service in Azure. After the first instance is restarted it shows up correctly in the database and becomes usable.
We're running CMS Core 18.104.22.168.
We can't recreate the issue on our development, QA or Stage environments. We're running two instances on our production environment, which might have something to do with it.
And just to note - the guid of the PageType is unique and we are running with enableModelSyncCommit enabled in production.
As your error message, the pkID is conflicted. This field is not guid of content type, this field type is integer, auto increment. I guess that many insert content type queries are called same time behind the scene
Every registering type appropriates to a parallel task so it is possible to occur problem as same as yours. See detail here https://world.episerver.com/csclasslibraries/cms/EPiServer.DataAbstraction.RuntimeModel.ContentTypeModelScanner?version=8#EPiServer_DataAbstraction_RuntimeModel_ContentTypeModelScanner_RunSynchronously
Are you using deployment slots? If a deployment slot, or instance, is running the old version of the code (without the page type) against the same database this problem could occur.
Hi thanks for your answers :)
@Binh, that would seem like a possible issue - but in both cases we've only been adding one new PageType, also even if multiple request are made wouldn't one of them go through - we've also only seen this issue in production (not on our development machines, qa or stage environment).
@Tomas, we are running deployment slots in prodution, but also in our QA environment were we haven't seen the issue. Could it be a mixture of multiple instances and deployment slots?