Minesh, did you try renaming the property then redeploying to both environments?

This commonly happens when you've decided you want to change the type of a property but once you've initalized the website, its too late to change it since its been generated as a new definition in the tables you've mentioned. But im sure you know this already!

Could a member of your team changed the type perhaps after it was already deployed to preprod?

Its quite a big squad and pre-prod was quite stale prior to us promoting the latest codebase. Renaming properties or Deleting Properties and than re-creating does do the trick just very frustrating. 

If their are no easier more efficient ways I'll stick to doing this, problem I have its quite a few properties causing me issues :( 

Minesh 

The most painful scenario is when it happens in Production, because then you need to worry about how to keep the data thats already been done by the real world editors!! There are some techniques to help with that.

If you really don't want to rename the property AND you don't care about the existing data against that property then you could create a migration step and delete the property and recreate it again.

I would personally just rename and be done with it.

Doing some more digging I dont believe the ModelTypeSync is running correctly. 

Utilising the ContentModelRepository I tried to programmatically determine the conflicts, too my surprise 0 conflicts were raised

Here is the Model and corresponding item in CMS

I currently have an open ticket with Optimizely Support and will keep this thread updated on progress, 

Thank you for reporting the issue. Yes it can be a bug when cms comapre property in model sync then it looking for type of PropertyDefinitionType which is PropertyBlock<BlockData> and in this case both PetNameFormField and TextFormFieldBlock has same PropertyDefinitionType. I'll rasie a bug for it and it will be investigated soon if it is the case.  

Thank you Shahram

You are experiencing this problem in Optimizely DXP in the preproduction environment?

It might be a long shot, but I would simply running another deploy! There can be problems where the deployment slots that gets swapped out hold an holder version of the code. When updating content type definitions, I always do a double-deploy...

We had tried re-deploying out again although the same issue and was able to replicate locally, it does seem like a bug, due to both the new and old types being local blocks and the Model Sync service not picking these up. I'll await Optimizely to confirm

I have now gone down the route of doing the following just so can get the team back up and running. 

• Delete all properties from code which are out of Sync in PPE Database
• Deploy to PPE
• Run job to remove these properties from Database on PPE 
• Add properties back in to PPE
• Re-Deploy to PPE
• Hand over for Content Population

I've encountered issues similar to this before with this before and found the following things helped:

Version your projects: Stamp your projects with a semantic version number and increment it with each release.  Optimizely CMS will recognize that version number and will ensure the database is sync'd up to the latest version when one of the load balanced instances is started up.  If two instances are up and running with the same semantic version but different code bases, the CMS won't force an update.

I've also found that sometimes the DB will not update when switching slots through the Paas Portal and this has also been resolved with a full restart of the environment.

Thank you all for Input, Optimizely have just confirmed it was identified as a bug and will be resolved in release 12.9.3 

https://world.optimizely.com/support/bug-list/bug/CMS-24976