We had report of this incident before but we could not gather enough data to draw a conclusion. However I suggest to make content type sync setting is disabled in Commerce Manager , at least to start with
This should be in web.config of Commerce Manager
<episerver> <applicationSettings enableModelSyncCommit="false" uiUrl="~/UI/" enableScheduler="false" /> </episerver>
Current Commerce Manager Web.config already has basically the same settings set, with the exception of uiUrl="~/EPiServer/CMS/":
So the problem is something else...do you have any other sites, like serviceapi?
To give an update; we didn't take any actions to solve this, but haven't seen it happen again.
Hi,
We also see this error from time to time in production. About every 2-3 weeks. We deploy frequently to test so I'm guessing that's why we don't see it there.
This is our error and it's the only thing I can see in the logs:
Unable to cast object of type 'Castle.Proxies.NodeContentProxy' to type 'Web.Features.BookNode.Models.BookNode'.
System.InvalidCastException: Unable to cast object of type 'Castle.Proxies.NodeContentProxy' to type 'Web.Features.BookNode.Models.BookNode'.
We have three sites. EPi+Commerce, Commerce Manager and EPi+Service API. "EPiServer.Commerce.Core" version="13.21.0"
After a restart it works fine again.
Thanks,
Rickard
Hi,
Version: Commerce 11.8.5
Setup: Admin, front1, front2, front3
We had an (2, technically) incident where all the content (Products, Variants, Categories...) in Commerce reverted back to its core implementation: Castle.Proxies.ProductContentProxy (etc) instead of our custom implementation, giving us EPiServer.Core.TypeMismatchException all over the place. Perhaps notable is that only Admin & Front3 seems to have been affected.
This was not preceeded by an IIS reset, App Pool Recycle or anything else that I can find in the System/Application logs; everything looks fine as far as I can see (checked around the time of the first occurance of the error +- a couple of hours.
The database looked fine which made us perform an IIS RESET which fixed the issue, however a lot of damage was already done by the time we realized the issue.
I'm just wondering if this is something known, our best guess is that it might be a bug in EpiServer. I haven't been able to find any details on issues that matches our issue on the forum, or anywhere else for that matter.
Timeline:
Deployed 11.8.5: 2018-08-15
...
First occurace on front3: 2018-09-08 23:37
Fixing IIS reset: 2018-09-09 22:20
...
First occurance on admin: 2018-09-12 13:33
Fixing IIS reset: 2018-09-13 09:21
These are the only occurances.
Any ideas are appreciated.
Thanks,
Fredrik