Five New Optimizely Certifications are Here! Validate your expertise and advance your career with our latest certification exams. Click here to find out more
AI OnAI Off
Five New Optimizely Certifications are Here! Validate your expertise and advance your career with our latest certification exams. Click here to find out more
Hello (Episerver) World!
I believe I have found a rather interesting little bug within the EPiServer.Marketing.KPI.2.4.1 package. I have searched through the release notes to see if a similar bug had been reported and fixed, but I did not find anything. I want to report what I found to see if there is a known solution for this issue and to raise awareness in case there is not a known solution. The site in question is currently running CMS 10.10.x.
To give some context, an editor recently started an A/B test on the Start Page with a "Time on Page" KPI and a "Site Stickiness" KPI. After this was set up, we started to see an increase in
NullReferenceException
being reported in Application Insights for a small set of global assets, including one in particular that was going to be included in a wide-ranging marketing email. Here is the stack trace for the error in question:After a bit of decompiling and debugging, I determined that the error seems to reliably occur when given the following:
EPiServer.Marketing.KPI.Common.StickySiteKpi.IsSupportingContent
ContentReference.StartPage
) in order to render navigation, footer, and the like as part of a multi-site setup.Given the above conditions, the Start Page will be loaded from the content repository as part of rendering the Not Found page and
EPiServer.Marketing.KPI.Common.StickySiteKpi.AddSessionOnLoadedContent
will subsequently be called. Because the Start Page is the content under test, and because the current url contains "/globalassets", and because the SSK_ cookie is not included in the request,EPiServer.Marketing.KPI.Common.StickySiteKpi.IsSupportingContent
will return "true" and the KPI will unsuccessfully attempt to dereferenceHttpContext.Current.Request.UrlReferrer.AbsolutePath
.Even though this bug mainly occurs when the url will cause a 404 response, if the server error response gets cached by the CDN for an asset that will eventually be published (which happened here), this can quickly become a large issue if the PDF/asset is highly important for some business reason. I don't have a question here per se but I am interested in any comments or critiques of my analysis as well as finding out if others have run into this problem :)
Thanks,
Christian