Try our conversational search powered by Generative AI!
AI OnAI Off
Failing constraint in EPiServer database - whole site unavailable
If it failed during initialization it isn't a maintenance routine as such. Episerver have a syncronisation of content types built into the initialization process.
My guess would be that you have configured your web host service to recycle the application pool around 3 AM, which would explain the restart of episerver and the calls to initialization modules at that time.
As it didn't bring the whole site down but it prevented the site from starting/going up it is debatable what should have happened. If episerver can't setup the content types it relies on should it really start the site? I agree though that the actual delete call could have been in a try-catch.
Feb 27, 2018 17:24
Correct - that is exactly what happened: the app pool recycled at that time which triggered the synchronization of content types in the initialization module.
I agree it can be debatable on what should happen if the full sync fails - probably it makes sense to not start the site, just as it works today.
However, this issue in particulcular seems more of a non-critical “clean up” part of the synchronization where non existing content types are to be deleted. Of course I don’t know the details and the logic in this internal module, but from my perspective any errors in this part should be ignored (but logged and possibly notifying the user) in order to successfully start the site. Don’t you agree? Would make it more robust.
Can I file a RFE/defect for this somewhere or do I need a partner account for that?
Feb 27, 2018 18:46
Syncronisation is more explained in this article including the option of disable commit/synchronisation. May be the disable option of commit be useful in your case?
https://world.episerver.com/documentation/Items/Developers-Guide/Episerver-CMS/9/Content/Synchronization/
Feb 27, 2018 21:00
Thanks, will look into if disabling sync/commit can be useful for us.
It is especially bullet 3 d) (Delete content types and properties) in that documentation that I would like to be wrapped in a try-catch and only be logged/ignored instead of failing the whole initialization/sync phase.
Feb 28, 2018 8:54
You can post your request in this forum:
https://world.episerver.com/forum/developer-forum/Feature-requests/
Feb 28, 2018 14:28
Thanks Erik.
Posted a request: https://world.episerver.com/forum/developer-forum/Feature-requests/Thread-Container/2018/2/ignore-certain-failures-in-the-synchronization-procedure-/
Feb 28, 2018 16:26
Follow up on this topic in https://world.episerver.com/forum/developer-forum/-Episerver-75-CMS/Thread-Container/2017/2/broken-episerver-got-broken/
Since one year back we are running separate EPiServer databases for our staging and production sites, which of course makes sense and works out great.
Yesterday we did "clean-up" maintenance on the production site where a lot content and content types were deleted. We had multiple sections of content and logic that has since long been "deprecated" (unpublished content, where corresponding controllers and logic is no longer in the code base). Of course we do no longer want that to exist in website and EPiServer (for security reasons, maintainability and what not). Most be quite common to try keeping environment clean and up-to-date right.
All went as planned except we where unable to delete one particular content type from the Admin mode. It was not reported as being in use or anything, it just did not disappear from the tree when deleting it. We thought we might just leave it like that as it is not in use in anyway. Bad decision.
At ~03:00 same night the whole site broke down. All requests failed in the EPiServer initialization phase, with exactly the same exception as in the linked topic (failed DB constraint when EPiServer eventually calls netContentTypeDelete). By using SQL Profiler I managed to identify what content type it was complaining about and sorted the issue manually.
Now, my main concern is: Is there some internal maintaince routine going in EPiServer at some time, which triggered this? And most importantly, the EPiServer logic ending up in the call to netContentTypeDelete - shouldn't that be wrapped in a try-catch-block and handled interally (raising some error logs or whatever), instead of bringing the whole site down?