0

After a pod restart (same image, no changes to previously working pod). No user can sign in to our CM instance (v10.1.3). The logs show the below error after a login attempt and I'm utterly stumped - any ideas? It's happened on two instances running separate images. I imagine it's something user related in the core DB?

ERROR Could not instantiate event handler. Type: Sitecore.Data.Fields.ItemEventHandler. Method: OnItemCopied (method: Sitecore.Events.Event.BuildConfigSubscribersFromConfiguration()).

Source: Sitecore.Events.Event.BuildConfigSubscribersFromConfiguration() at Sitecore.Diagnostics.Error.Raise(String error, String method) at Sitecore.Events.Event.EventSubscribers.Add(String eventName, XmlNode configNode) at Sitecore.Events.Event.BuildConfigSubscribersFromConfiguration() at Sitecore.DependencyInjection.LazyResetable`1.get_Value() at Sitecore.Events.Event.RaiseEvent(String eventName, Object[] parameters) at Sitecore.Data.Properties.PropertyStore.RaiseEvent(String name, Object[] parameters) at Sitecore.Web.Authentication.DefaultTicketManager.RemoveTicket(String ticketId) at Sitecore.Owin.Authentication.Pipelines.CookieAuthentication.SignIn.RemoveTicket.Process(SignInArgs args) at (Object , Object ) at Sitecore.Pipelines.CorePipeline.Run(PipelineArgs args) at Sitecore.Pipelines.DefaultCorePipelineManager.Run(String pipelineName, PipelineArgs args, String pipelineDomain, Boolean failIfNotExists) at Sitecore.Pipelines.DefaultCorePipelineManager.Run(String pipelineName, PipelineArgs args, String pipelineDomain) at Sitecore.Owin.Authentication.Security.Cookies.DefaultCookieAuthenticationProvider.ResponseSignIn(CookieResponseSignInContext context) at Microsoft.Owin.Security.Cookies.CookieAuthenticationHandler.d__13.MoveNext() in /_/src/Microsoft.Owin.Security.Cookies/CookieAuthenticationHandler.cs:line 310

EDIT

On restarting the instance I think we have another clue, it's unable to start the core db agent

3168 10:34:16 ERROR Error while instantiating agent. Definition: core/sitecore/system/tasks/schedulestrue Exception: Sitecore.Exceptions.ConfigurationException Message: Could not create object from service provider . Config XML: core/sitecore/system/tasks/schedulestrue Source: Sitecore.Kernel at Sitecore.Configuration.DefaultFactory.CreateFromServiceProvider(XmlNode configNode, Boolean assert) at Sitecore.Configuration.DefaultFactory.CreateObject(XmlNode configNode, String[] parameters, Boolean assert, IFactoryHelper helper) at Sitecore.Configuration.DefaultFactory.CreateObject(XmlNode configNode, Boolean assert) at Sitecore.Tasks.Scheduler.Agents.DefaultAgentsConfigReader.Parse(XmlNode agentConfigNode)

Nested Exception Exception: System.InvalidOperationException Message: Unable to resolve service for type 'System.String' while attempting to activate 'Sitecore.Tasks.DatabaseAgent'. Source: Microsoft.Extensions.DependencyInjection.Abstractions at Microsoft.Extensions.DependencyInjection.ActivatorUtilities.ConstructorMatcher.CreateInstance(IServiceProvider provider) at Microsoft.Extensions.DependencyInjection.ActivatorUtilities.CreateInstance(IServiceProvider provider, Type instanceType, Object[] parameters) at Sitecore.Configuration.DefaultFactory.CreateFromServiceProvider(XmlNode configNode, Boolean assert)

Improve this question
4
  • Do you have any persistent storage setup? Is there any chance some config might be altered or missing on second initialisation? or a file is copied to a location 1st time, then unable to copy 2nd time dure to already existing? Try making copy of app_config and App_data folder from 1st and 2nd run and compare.
    – Dean OBrien
    Commented Sep 11, 2023 at 12:30
  • @DeanOBrien No I think we can rule that out as running a fresh deployment via the build pipeline gives us the same results.
    – Sean T
    Commented Sep 11, 2023 at 14:08
  • ah ok so this happens all the time now? Not just between 1st and 2nd run
    – Dean OBrien
    Commented Sep 11, 2023 at 16:28
  • @DeanOBrien I think I have it, there was a 10.1.3-pre hotfix a couple months back. They have just released 10.1.3 for real so removing the hotfix stage from the pipeline appears to have fixed whatever conflict there was. Just testing in staging at the moment
    – Sean T
    Commented Sep 12, 2023 at 12:13

1 Answer 1

Reset to default
0

There was a security bulletin from Sitecore that involved patching with a 10.1.3-pre delta asset image a while back.

https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB1003018

Sitecore recently released 10.1.3 fully, which must have contained breaking changes from the pre-release version.

So our pipeline was building from 10.1.3, then applying 10.1.3-pre assets, causing the conflict and as a result the error.

This doesn't explain why it only occurred in Production following a pod restart and not an image rebuild, or pipeline release. I'd be interested to hear any ideas if anyone has a theory.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.