search

umbraco / Umbraco-CMS

Umbraco is a free and open source .NET content management system helping you deliver delightful digital experiences.
https://umbraco.com
MIT License
4.45k stars 2.68k forks source link

This document is published but its url cannot be routed #9514

Closed sbosell closed 3 years ago

sbosell commented 3 years ago

Sometimes a node in umbraco will be in a state of published but not routable when this should not be allowed to occur. Umbraco in this case throws a 404 for that route.

There are several cases of this being reported as well as other issues reported here (duplicate)

Related to issue #7575

Umbraco version

I am seeing this issue on Umbraco version: 8.6.2, 8.7.x, and 8.9.1

Reproduction

I have a process that syncs data in the backend every 30 minutes to a node's descendants and then the content api calls SaveAndPublish and/or SaveAndPublishBranch (tested with both in the sync). The sync uses the content api via a recurring task, all standard features of Umbraco. In my case we have no cultures defined and only one root site. The most basic Umbraco setup. Others are reporting the same issue so it may have nothing to do with the Content Api.

About 1 time per day the root node of the sync will be in this state of the url can't be routed and it is random in that it only occurs every once in a while which leads me to believe there is a locking mechanism with how the cache works. This should never happen, there should be no code path that unpublished or deroutes a node like this in the save and publish.

Hosted on Azure in a single site (not load balanced) with all the appropriate settings set via the Umbraco Documentation.

Bug summary

A node becomes not routable when this should never happen.

Specifics

I can privately provide a URL

Steps to reproduce

It happens randomly

Expected result

A valid published node in Umbraco should NEVER be in a state of the URL not being routable.

Actual result

Umbraco backend reports the URL not being routable and the node is effectively unpublished.

_This item has been added to our backlog AB#9840_

Shazwazza commented 3 years ago

@sbosell This how the nucache controller works in the back office: https://github.com/umbraco/Umbraco-CMS/blob/v8/contrib/src/Umbraco.Web/Editors/NuCacheStatusController.cs#L60 ... if you need to currently need to resort to brute force techniques

MartinThomasCW commented 3 years ago

@Shazwazza - nothing in particular about the pages that clash - they are publicly accessible, but serve as the landing pages to the premium content. Their children are protected content (secured with standard role based access checks). Recently there has also been another page in the non "premium" section that got un-routed. Literally nothing special about that page that i can tell either.

Worth mentioning that I have executed your CheckAndFixPaths sql script, but that returned no results. Good in one regard, but it's the hope that kills you when you're looking for a fix! :)

benbracedigital commented 3 years ago

@Shazwazza We have no IContentFinder, UrlProviders, UmbracoVirtualNodeRouteHandler on our site. The pages which this affects is completely random. Some are one level deep, some are two or three levels deep. From an Umbraco perspective, the affected pages are doing nothing special. They call SurfaceControllers to render forms but don't even have their own RenderControllers. Today I'm setting up uptime alerts on a lot of the pages to get a good understand of how often they go down and which pages as currently we're relying on our client and users telling us when pages are down which isn't a good look.

MartinThomasCW commented 3 years ago

Apologies @Shazwazza , totally forgot to answer your main question! No, we don't have any custom IContentFinder, UrlProviders or UmbracoVirtualNodeRouteHandlers.

ronaldbarendse commented 3 years ago

In the related issues someone noted that they could fix the broken nodes by rebuilding the cache.

I've seen similar issues after changes were deployed using Umbraco Deploy (on the live environment on Umbraco Cloud): it randomly breaks the content cache and manually rebuilding the cache is the only way to fix this. This also happens on very simple sites (using culture variants with only a path configured on the single root node, e.g. /en and /nl for the respective languages).

One of the things I noticed in the logs is Umbraco Deploy suspending the document cache (message: Suspend document cache., context: Umbraco.Web.Suspendable+PageCacheRefresher) and later resuming it without reloading (message: Resume document cache (reload:False).). And whenever it has happened, I also noticed the caches had multiple generations and/or snapshots: rebuilding the cache always resulted in 1 generation and 1 snapshot).

ronaldbarendse commented 3 years ago

I've found these steps (while debugging another issue: https://github.com/umbraco/Umbraco-CMS/issues/9751) that are reproducable:

There are 2 ways to fix the content cache (and make the content routable again):

  1. Publishing the root node with all descendants: this increased the cache generation count
  2. Reloading the memory cache: this updated the generation count back to 1 (and if it didn't, a 'collect' would)

Also note: when the cache was in this corrupt state, only publishing the unroutable content increased the generation count without fixing the issue.

nikolajlauridsen commented 3 years ago

Thanks a lot for your steps to reproduce @ronaldbarendse. I've tried to follow your instruction, but unfortunately, with no luck, I've made a little video of my attempt, if you have a minute to check if I'm misunderstanding your steps that would be awesome.

I'm no video making expert but hopefully it's understandable.

https://user-images.githubusercontent.com/16456704/106766856-8f1b4f00-663a-11eb-9a45-43cbaad83532.mp4

kimschurmann commented 3 years ago

This is starting to become a serious issue for us - any progress or work being done? Still umbraco 8.5.5.

kimschurmann commented 3 years ago

Any hack or work around tip would be appreciated...

bergmania commented 3 years ago

@kimschurmann, We are still investigating and work on this task. We still need a solid way to reproduce it, so any help is welcome.

Especially feedback on @nikolajlauridsen's video would be interesting.

Shazwazza commented 3 years ago

Hello everyone,

Can anyone/everyone tell me if they have this package installed or not? https://our.umbraco.com/packages/website-utilities/virtualnodes/

This is one of causes of this error and will occur depending on how your site is setup and how you have configured this.

benbracedigital commented 3 years ago

@Shazwazza We do NOT have this installed.

MartinThomasCW commented 3 years ago

Nope, nor do we, sorry

sbosell commented 3 years ago

I don't have it installed either.

Nicholas-Westby commented 3 years ago

Same, don't have VirtualNodes installed.

Zweben commented 3 years ago

Still having pretty frequent issues with the homepage effectively going unpublished immediately after a deployment.

No VirtualNodes package installed, or any other Umbraco packages for that matter. I'm also working towards getting our site down to one root node, to see if that improves anything.

Shazwazza commented 3 years ago

Thanks all.

@Zweben it is very difficult here to track what everyone is doing and have tried. I mentioned above about how root nodes and domains work. You don't need to have a single root node to test, you just need to have domains properly assigned as to avoid any ambiguous routes, see https://github.com/umbraco/Umbraco-CMS/issues/9514#issuecomment-770515412. But I would be interested to see if the problem still exists with a single root node. Right now any testing, help, feedback, etc... is most welcome to move the investigation along.

This is how you would setup a tree to cause the ambiguous routes issue - none of these nodes have domains and HideTopLevelNodeFromPath = true (the default). If you setup a tree like this then "Home" will be ambiguous because it's trying to make the URL /home for both nodes and there's no guarantee which Home will be the matching one.

However, in this case I don't think that ambiguous routes and missing domains is the issue because testing this, the error message in the UI is this: "This document is published but its URL would collide with content /Brand A/Home (id=123456)"

That said - the way to avoid this and possibly other routing issues is to ensure that domains are assigned (even if they are dummy domains for settings nodes, etc...) at the root level nodes if multiple root nodes exist. It is still worth trying this if you don't have this setup to see if helps.

This particular error message: "This document is published but its url cannot be routed" is when no content can be resolved to the URL that's being tried. Unfortunately there is no logging that occurs when this happens. I've created a PR which will hopefully be in the next patch version which will help shed some light on this hopefully: https://github.com/umbraco/Umbraco-CMS/pull/9830/files#diff-cd06d5e77b193e5227cafc506b674f6620ba39c5c4f36acd55439db48ae573a0R195

There is certainly some different issues at play here and each persons environment/setup will probably have some varying thing. For example, one of the issues for some was the VirtualNodes package.

Shazwazza commented 3 years ago

@MartinThomasCW is your site an Umbraco Cloud site? If so, would it be possible to invite me as an admin to help investigate? (shannon at umbraco dot com). And/or if at all possible to enable this verbose logging in the serilog.config file: <add key="serilog:minimum-level:override:Umbraco.Web.Routing.PublishedRouter" value="Debug" /> just so that it's enabled when this issue happens and then it can be turned off again. It's quite verbose so will log a lot. If that's possible could you email me those logs?

nzdev commented 3 years ago

As a note as I have experienced some issues perhaps related, I've seen ObjectDisposedException occur for the snapshot class in nucache when trying to route. Also if the routes collide from two root nodes I've also seen this sort of issue.

Shazwazza commented 3 years ago

@nzdev if you have, remember or gather any further bits of information on this please let me know (stack traces, etc...)

MartinThomasCW commented 3 years ago

@Shazwazza it's not umbraco cloud, but i'll check with the client for access - not a problem as far as i'm concerned though. Logging added and going out imminently (they were due a release for other fixes so good timing!)

Zweben commented 3 years ago

@MartinThomasCW is your site an Umbraco Cloud site? If so, would it be possible to invite me as an admin to help investigate? (shannon at umbraco dot com). And/or if at all possible to enable this verbose logging in the serilog.config file: <add key="serilog:minimum-level:override:Umbraco.Web.Routing.PublishedRouter" value="Debug" /> just so that it's enabled when this issue happens and then it can be turned off again. It's quite verbose so will log a lot. If that's possible could you email me those logs?

Ours is an Umbraco Cloud site; I could probably invite you to the project if you think it would help. I'll also try to remember to turn on verbose logging next time I publish something to Live.

sbosell commented 3 years ago

My site is hosted in an Azure Web App in the simplest way without any scale out (not Umbraco Cloud). Is everyone else hosted on Azure or does anyone here self host?

Nicholas-Westby commented 3 years ago

@sbosell We host ourselves (in an AWS VM, which AWS refers to as EC2).

benbracedigital commented 3 years ago

We host the site on our own VPS. Not Umbraco Coud or other cloud such as Azure or AWS

sbosell commented 3 years ago

@benbracedigital @Nicholas-Westby I thought this might have been related to how Azure Web App's manage their underlying infrastructure (nodes spin up and down and connect to a virtual file system) but if you are self-hosting on a Virtual Machine that points to something more general in my mind. I went through the code for when a route is looked up but I don't think that's the issue, something in the cache layer I think is derouting these nodes in some way.

Shazwazza commented 3 years ago

@Zweben

I could probably invite you to the project if you think it would help. I'll also try to remember to turn on verbose logging next time I publish something to Live.

Yes it would certainly help me if you could invite me that would be great and also let me know if/when you enable that logging. It only needs to be enabled before and up to when you experience this issue and then can be disabled again.

Shazwazza commented 3 years ago

Hi all - another question for everyone: For any items that become un-routable, are you using any of the built in 'special' umbraco route property types: umbracoUrlAlias, umbracoUrlName, umbracoRedirectId or umbracoRedirect?

nzdev commented 3 years ago

Unrelated error

Shazwazza commented 3 years ago

@nzdev is this related to "This document is published but its url cannot be routed" or a different issue that you are reporting? This seems unrelated.

nzdev commented 3 years ago

It may or not be related, happy to raise as a different issue.

benbracedigital commented 3 years ago

Hi all - another question for everyone: For any items that become un-routable, are you using any of the built in 'special' umbraco route property types: umbracoUrlAlias, umbracoUrlName, umbracoRedirectId or umbracoRedirect?

None of those are used on our site that is affected.

creativesuspects commented 3 years ago

Not sure if it helps, but I noticed this issue also affects Multinode Treepicker data types where the root node is set based on an xpath query. I was using the following xpath query '$site/jobListing' for a 'Job Picker' data type. When I tried to select a job using the picker I noticed the overlay was showing the full content tree instead of just the content underneath the 'jobListing' page (which is fallback behavior for a faulty xpath query). When I checked the 'jobListing' page it wasn't published due to the 'routing' issue. After rebuilding the cache the issue was gone and the picker worked as intended again.

Umbraco version: 8.11.1

I don't have the Virtual Nodes package installed and I'm not using the routing properties umbracoUrlAlias, umbracoUrlName, umbracoRedirectId or umbracoRedirect.

sbosell commented 3 years ago

Hi all - another question for everyone: For any items that become un-routable, are you using any of the built in 'special' umbraco route property types: umbracoUrlAlias, umbracoUrlName, umbracoRedirectId or umbracoRedirect?

The node that is being derouted has the special properties (I add them to all content nodes) but none of them are in use.

Nicholas-Westby commented 3 years ago

Hi all - another question for everyone: For any items that become un-routable, are you using any of the built in 'special' umbraco route property types: umbracoUrlAlias, umbracoUrlName, umbracoRedirectId or umbracoRedirect?

Nope, we aren't using those properties.

MartinThomasCW commented 3 years ago

Nope, we aren't either. We have umbracoUrlAlias defined, but not a single node uses it

Shazwazza commented 3 years ago

@orsinic wondering if you would be able to invite me to one of your Cloud projects exhibiting this issue? (shannon at umbraco dot com)

Zweben commented 3 years ago

@Zweben

I could probably invite you to the project if you think it would help. I'll also try to remember to turn on verbose logging next time I publish something to Live.

Yes it would certainly help me if you could invite me that would be great and also let me know if/when you enable that logging. It only needs to be enabled before and up to when you experience this issue and then can be disabled again.

I sent you an invite.

Shazwazza commented 3 years ago

@Zweben many thanks. Based on your above comments I noticed you mentioned this occurs mostly with the home page? I assume you mean the very first node in your tree? And when you've mentioned it occurs after a "deployment" - can you tell me what type of deployment specifically? A content deployment or a git/schema deployment? And any item(s) in particular? If I can know these answers I can try to replicate.

kimschurmann commented 3 years ago

@Zweben many thanks. Based on your above comments I noticed you mentioned this occurs mostly with the home page? I assume you mean the very first node in your tree? And when you've mentioned it occurs after a "deployment" - can you tell me what type of deployment specifically? A content deployment or a git/schema deployment? And any item(s) in particular? If I can know these answers I can try to replicate.

Using Azure WebApps with deployment slots and using uSync to sync changes to production. First thought was that the swapping of disks when using deployment slots could invalidate the cache layer - but can't reproduce it. Another thought was that it could be uSync - but can't reproduce that either...

Zweben commented 3 years ago

@Zweben many thanks. Based on your above comments I noticed you mentioned this occurs mostly with the home page? I assume you mean the very first node in your tree? And when you've mentioned it occurs after a "deployment" - can you tell me what type of deployment specifically? A content deployment or a git/schema deployment? And any item(s) in particular? If I can know these answers I can try to replicate.

In the past, this or a similar issue has happened on other nodes, but currently it seems to only affect the homepage. The homepage is one of two root nodes currently, but it's the node that has 99% of the content under it.

The issue seems to occur after doing a git/schema deployment from Development to Live in the Umbraco.io portal. After the deployment, the homepage will show a 404 error, and I will have to reload the database cache before it will display properly again. Please note that we have the site behind Cloudflare as a proxy, so that masks the issue sometimes, but not always.

Zweben commented 3 years ago

@MartinThomasCW is your site an Umbraco Cloud site? If so, would it be possible to invite me as an admin to help investigate? (shannon at umbraco dot com). And/or if at all possible to enable this verbose logging in the serilog.config file: <add key="serilog:minimum-level:override:Umbraco.Web.Routing.PublishedRouter" value="Debug" /> just so that it's enabled when this issue happens and then it can be turned off again. It's quite verbose so will log a lot. If that's possible could you email me those logs?

@Shazwazza I just did a deployment from Dev to Live that also contained the serilog config change to enable debug logging. It doesn't look like any errors occurred this time, though. Is it safe to leave debug logging on until our next deployment, to give it another shot?

creativesuspects commented 3 years ago

@Shazwazza I’ve been dealing with quite a few derouted node issues on a local dev environment. I will also enable debug logging and I’ll send you the logs when it happens again.

Shazwazza commented 3 years ago

@Zweben in your case, I can replicate issues when transferring schema. I don't get the home page as "document is published but its url cannot be routed" but instead on the child page "Who we..." when clicked I get a YSOD (I'm running with debug=true) in the web.config. There's a null reference exception coming from Your code in your content finder (i've obfuscated a few things):

NullReferenceException
at A.B.C.ChildSiteHelper.GetChildSiteSegmentFromUrl(Uri uri)
   at A.B.C.ChildSiteHelper.IsChildSiteRequest(Uri uri)
   at A.B.C.ChildSiteContentFinder.TryFindContent(PublishedRequest request)
   at System.Linq.Enumerable.Any[TSource](IEnumerable`1 source, Func`2 predicate)
   at Umbraco.Web.Routing.PublishedRouter.FindPublishedContent(PublishedRequest request)
   at Umbraco.Web.Routing.PublishedRouter.TryRouteRequest(PublishedRequest request)
   at Umbraco.Web.Routing.UrlProviderExtensions.DetectCollision(IContent content, String url, String culture, UmbracoContext umbracoContext, IPublishedRouter publishedRouter, ILocalizedTextService textService, UrlInfo& urlInfo)
   at Umbraco.Web.Routing.UrlProviderExtensions.<GetContentUrlsByCulture>d__1.MoveNext()
   at Umbraco.Web.Routing.UrlProviderExtensions.<GetContentUrls>d__0.MoveNext()
   at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
   at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
   at Umbraco.Web.Models.Mapping.ContentMapDefinition.Map(IContent source, ContentItemDisplay target, MapperContext context)
   at Umbraco.Core.Mapping.UmbracoMapper.Map[TTarget](Object source, Type sourceType, MapperContext context)
   at Umbraco.Core.Mapping.UmbracoMapper.Map[TTarget](Object source, MapperContext context)
   at Umbraco.Web.Editors.ContentController.MapToDisplay(IContent content)
   at lambda_method(Closure , Object , Object[] )
   at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.<>c__DisplayClass6_2.<GetExecutor>b__2(Object instance, Object[] methodParameters)
   at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ExecuteAsync(HttpControllerContext controllerContext, IDictionary`2 arguments, CancellationToken

The major problem is that you have static references to request based instances (as I can see in ChildSiteHelper... there's possibly others too), for example:

public static UmbracoContext _umbracoContext => Umbraco.Web.Composing.Current.UmbracoContext;

This absolutely cannot be done. The UmbracoContext is a request based lifetime and is based on the HttpContext. This is pinning this to the root of the app which is immediately stale and will hold all cache references to old stale caches (among many many other problems if you do this). This is described in the Common Pitfalls docs: https://our.umbraco.com/documentation/reference/common-pitfalls/#static-references-to-web-request-instances-such-as-umbracohelper

Can everyone make sure you are not pinning non-singletons to the root as statics. This will absolutely cause all sorts of problems like this one.

My advice is to just stop using statics all together. It will make your code safer, more manageable, makes spaghetti code far more difficult to make, prevents memory leaks and prevents problems like there where a non-singleton object is pinned to the root as a singleton. Avoid statics and please use dependency injection it will make your code so much cleaner, easier to manage and you don't run into these problems.

If anyone exhibiting this issue can report back if this is their underlying problem it will be very helpful.

sbosell commented 3 years ago

@Shazwazza Related to your last message and mentioned in my opening text, we have a sync processing running every 30 minutes and are publishing the node that is having issues as well as its child nodes. I used the RecurringTaskBase example from the docs which looks something like: `

 public class MenuSync : RecurringTaskBase
    {
        private IRuntimeState _runtime;
        private IProfilingLogger _logger;
        private IContentService _contentService;

        private IUmbracoContextFactory _umbracoContextFactory;
        private IScopeProvider _scopeProvider;
        public MenuSync(IBackgroundTaskRunner<RecurringTaskBase> runner, int delayBeforeWeStart, int howOftenWeRepeat, IRuntimeState runtime, IProfilingLogger logger, IContentService contentService, IUmbracoContextFactory umbracoContextFactory, IScopeProvider scopeProvider)
            : base(runner, delayBeforeWeStart, howOftenWeRepeat)
        {
            _runtime = runtime;
            _logger = logger;
            _contentService = contentService;
            _umbracoContextFactory = umbracoContextFactory;
            _scopeProvider = scopeProvider;
        }

The part that may be of question is that the only way I could get this to work with publishing and saving the content was to call EnsureUmbracoContext like below but perhaps that's not correct? In my case ProcessLocation is calling Save or SaveAndPublish on each node that is being synced. Is this correct?

public override bool PerformRun()
        {
            long count; 
            var locationsRoot = _contentService.GetById(1077);
            var locationsPublish = _contentService.GetPagedOfType(1073, 0, 1000, out count, null);

            using (var umb = _umbracoContextFactory.EnsureUmbracoContext())
            {

                    // do the publish stuff here 
                    foreach (var loc in locationsPublish)
                    {
                        ProcessLocation(loc);
                    }
            }
Zweben commented 3 years ago

@Zweben in your case, I can replicate issues when transferring schema. I don't get the home page as "document is published but its url cannot be routed" but instead on the child page "Who we..." when clicked I get a YSOD (I'm running with debug=true) in the web.config. There's a null reference exception coming from Your code in your content finder (i've obfuscated a few things):

NullReferenceException
at A.B.C.ChildSiteHelper.GetChildSiteSegmentFromUrl(Uri uri)
   at A.B.C.ChildSiteHelper.IsChildSiteRequest(Uri uri)
   at A.B.C.ChildSiteContentFinder.TryFindContent(PublishedRequest request)
   at System.Linq.Enumerable.Any[TSource](IEnumerable`1 source, Func`2 predicate)
   at Umbraco.Web.Routing.PublishedRouter.FindPublishedContent(PublishedRequest request)
   at Umbraco.Web.Routing.PublishedRouter.TryRouteRequest(PublishedRequest request)
   at Umbraco.Web.Routing.UrlProviderExtensions.DetectCollision(IContent content, String url, String culture, UmbracoContext umbracoContext, IPublishedRouter publishedRouter, ILocalizedTextService textService, UrlInfo& urlInfo)
   at Umbraco.Web.Routing.UrlProviderExtensions.<GetContentUrlsByCulture>d__1.MoveNext()
   at Umbraco.Web.Routing.UrlProviderExtensions.<GetContentUrls>d__0.MoveNext()
   at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
   at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
   at Umbraco.Web.Models.Mapping.ContentMapDefinition.Map(IContent source, ContentItemDisplay target, MapperContext context)
   at Umbraco.Core.Mapping.UmbracoMapper.Map[TTarget](Object source, Type sourceType, MapperContext context)
   at Umbraco.Core.Mapping.UmbracoMapper.Map[TTarget](Object source, MapperContext context)
   at Umbraco.Web.Editors.ContentController.MapToDisplay(IContent content)
   at lambda_method(Closure , Object , Object[] )
   at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.<>c__DisplayClass6_2.<GetExecutor>b__2(Object instance, Object[] methodParameters)
   at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ExecuteAsync(HttpControllerContext controllerContext, IDictionary`2 arguments, CancellationToken

The major problem is that you have static references to request based instances (as I can see in ChildSiteHelper... there's possibly others too), for example:

public static UmbracoContext _umbracoContext => Umbraco.Web.Composing.Current.UmbracoContext;

This absolutely cannot be done. The UmbracoContext is a request based lifetime and is based on the HttpContext. This is pinning this to the root of the app which is immediately stale and will hold all cache references to old stale caches (among many many other problems if you do this). This is described in the Common Pitfalls docs: https://our.umbraco.com/documentation/reference/common-pitfalls/#static-references-to-web-request-instances-such-as-umbracohelper

Can everyone make sure you are not pinning non-singletons to the root as statics. This will absolutely cause all sorts of problems like this one.

My advice is to just stop using statics all together. It will make your code safer, more manageable, makes spaghetti code far more difficult to make, prevents memory leaks and prevents problems like there where a non-singleton object is pinned to the root as a singleton. Avoid statics and please use dependency injection it will make your code so much cleaner, easier to manage and you don't run into these problems.

If anyone exhibiting this issue can report back if this is their underlying problem it will be very helpful.

Oof, thank you @Shazwazza for identifying that. I wrote this code back when there was barely any Umbraco 8 documentation yet; it has improved dramatically since then.

I believe I fell into that trap in part because I had extension methods in the class that tied into the other methods. I think I'm going to need change this entire class into a custom service, so it's no longer static and can be injected into views. I'll also do a search through our code-base for static references to any Umbraco objects, and try to get rid of all of them. You're a huge help!

Edit: I have gone through our code-base and replaced every static or non-DI use of an Umbraco object with an equivalent DI implementation. I'll report back if we continue to see cache issues.

kimschurmann commented 3 years ago

Any progress made on this? We are still stuck on 8.5.5 - any one knows if the problem will get worse if we upgrade?

bergmania commented 3 years ago

@kimschurmann as you can see from @Shazwazza's answers in this thread. We have still not found anything in Umbraco that leads to this directly. In the cases @Shazwazza have looked into so far, it has been custom code or packages with custom code that was the root cause.

Did you check your solution do not suffer for the same issues as described in @Shazwazza's answers?

Regarding whether it will be worse if you upgrade, we currently don't think so.

kimschurmann commented 3 years ago

@kimschurmann as you can see from @Shazwazza's answers in this thread. We have still not found anything in Umbraco that leads to this directly. In the cases @Shazwazza have looked into so far, it has been custom code or packages with custom code that was the root cause.

Did you check your solution do not suffer for the same issues as described in @Shazwazza's answers?

Regarding whether it will be worse if you upgrade, we currently don't think so.

We have a couple of places where we use Current.UmbracoContext - is that a problem too?

But it is not pinned as a static though!

bergmania commented 3 years ago

We have a couple of places where we use Current.UmbracoContext - is that a problem too?

But it is not pinned as a static though!

That should be okay. You do not have any custom content finders? If you have, please ensure these are not introducing the issue.