Missed Scope and Missed ScopeContext errors from ContentService calls

[Attackmonkey]

Which Umbraco version are you using?

8.12.1

Bug summary

When calling the ContentService and saving and publishing in a UmbracoAuthorizedApiController controller from a service that's injected into the controller, we get two warnings after each save and publish. One says something like:

Missed "ScopeContext" Object "4a98e5d3"

And the one after says:

Missed "Scope" Object "233aadc2"

The object IDs are different for each log entry.

Specifics

So, we have an UmbracoAuthorizedApiController controller that is called from a dashboard in the back office. The dashboard accepts a CSV file and this is parsed and new items are added to the content tree using the ContentService. All of the methods are async.

We have a service that does all the actual work, that is injected into our UmbracoAuthorizedApiController controller using the built in IoC. That service has the ContentService passed in as a dependency using IoC as per the standard Umbraco docs.

Whenever the service is called, every time we save and publish, we get scope warnings in the logs. One after the other, like this:

Missed "ScopeContext" Object "4a98e5d3"

Missed "Scope" Object "233aadc2"

We get these for each item that is save and published in the service.

Steps to reproduce

Create an UmbracoAuthorizedApiController with async methods that calls the content service from an injected service.

Expected result / actual result

Items should be saved and published without throwing a warning.

[nul800sebastiaan]

Hmmm 🤷 but does it give any problems? :-)

Code is here: https://github.com/umbraco/Umbraco-CMS/blob/v8/contrib/src/Umbraco.Core/Scoping/ScopeProvider.cs#L121

We'd be happy if you want to investigate, apparently something with statics.

[Attackmonkey]

OK, on further investigation I think this is ACTUALLY caused by calling EnsureUmbracoContext() inside the service, as per the recommended way of getting the published content query.

It looks like because the EnsureUmbracoContext method tries to get the context, and as it's null (because we're in a background task as it's async), it spins up the new context, but the code that gets it in the first place logs a warning, because the context was null at first.

Is this something that should be logged as a warning? It doesn't look like it has any negative effect, and if you're running background tasks it can fill up the logs a LOT.

[umbrabot]

Hi @Attackmonkey,

We're writing to let you know that we would love some help with this issue. We feel that this issue is ideal to flag for a community member to work on it. Once flagged here, folk looking for issues to work on will know to look at yours. Of course, please feel free work on this yourself ;-). If there are any changes to this status, we'll be sure to let you know.

For more information about issues and states, have a look at this blog post

Thanks muchly, from your friendly Umbraco GitHub bot :-)

[Shazwazza]

This is most likely related to using async and/or a combination of fire and forget along with issues with flowing the execution context and scopes. You can force this problem by creating a scope and then doing a fire and forget Task.Run and then different combinations of disposing the scope from within that child task, etc... The Scope flows with ExecutionContext and therefore flows to async calls. This can be very dangerous if things are not awaited correctly.

There's some recent fixes relating to this too, see #9953

For further information, here's a larger writeup based on changes required for v9 to understand this more #9926

Here's a gist on showing how ExecutionContext is flowed https://gist.github.com/Shazwazza/c127e8c567ab505d146e54ac802a9945

[Attackmonkey]

Hi Shannon,

Thanks for getting back to me!

We were getting issues where the site would have a SQL Timeout while indexing during import using the API, which would cause the indexes to break and not have the right amount of things in. Upgrading to the latest Examine seems to have fixed it, but will upgrade Umbraco too.

We'e tracked down the source the scope error though. It appears to be in our indexing event handler for Examine, which runs on the index gathering event. In that event, we inject IUmbracoContextFactory and then call EnsureUmbracoContext(), as per the docs for getting the umbraco content helper, as we fetch a picked node and save some of it's properties to the node it was picked on to use in search filters.

The warnings appears to come from that handler (they disappear if we comment out the handler). My guess is because the task is running async, there's no context to get the first time, so the context fetcher logs the warning before creating the scope?

Since upgrading to the latest Examine, the warnings are gone though :)

[Shazwazza]

It's fixed for the same reason - ExecutionContext flowing incorrectly to background threads. Examine has it's own internal fix for this but also later versions of Umbraco do too.

[Attackmonkey]

Awesome, I'll flag this as closed then, as the upgrade sorted it! Thanks Shannon :)