SaaS CMS has officially launched! Learn more now.

Common Issue; Unable to cast an object of type 'X' to type 'Y'


Hey all, you most probably all have had to deal with this situation at some point when working with Content Cloud, basically an editor cant publish changes as the property type is out of synch in database compared to what it is in code. 

When coming across this issue we normally have to start with a fresh database or fiddle with the existing database inside the following tables [tblPropertyDefinitionType] and [tblPropertyDefinition]

Firstly I would like to understand why when deploying from one environment to another this issue occurs, and secondly is their a better way to resolve this issue. 

I have looked at the assembley version numbers and am incrementing this so this is not the issue. 



Sep 08, 2022 14:58

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?

Sep 08, 2022 19:52

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 :( 


Sep 09, 2022 9:10

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.

Sep 09, 2022 9:16

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, 

Sep 09, 2022 12:17

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.  

Sep 14, 2022 9:05

Thank you Shahram

Sep 14, 2022 13:59

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...

Edited, Sep 14, 2022 14:03

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
Sep 14, 2022 14:08

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.

Oct 03, 2022 16:08

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

Oct 11, 2022 11:15
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.