This code produces a "Recursive locks not allowed" error in production, but not in test or development. So I'm guessing the Production Runtime Mode is the reason.

if (item.Published && umbracoContentService.IsPathPublishable(item))

umbracoContentService.SaveAndPublish(item);

Does anyone have any spontaneous ideas on what could cause this? The item comes from

contentService.GetPagedOfType(...)

.

Your code doesn't show any scopes, maybe you have them, but you should use them everywhere when doing write operations.

Interesting. I can't find anything about this in the docs. Do you have a link I can educate myself with? I don't think I've ever used a scope in Umbraco.

Looks like we don't have that much documented, but check out the example here, the important bits being

using ICoreScope scope = _coreScopeProvider.CreateCoreScope();

and

scope.Complete()

when the work is done. https://docs.umbraco.com/umbraco-cms/10.latest/reference/notifications/creating-and-publishing-notifications#sending-notifications

We're not using a background job, this is an API controller called from outside that potentially modifies stuff in Umbraco. So I wouldn't have thought those docs to apply. Thanks. So if I interpret you correctly we should

CoreScope

all our

ContentService

operations in our API controller, especially the write operations?

I think it might not be documented because we apply scopes automatically when doing these things, so it might not always be needed. But since you're clearly doing recursive work, you might need to state the locks explicitly. That said, if you are already doing recursive work, recursive locks would still not be allowed so you're back to square one 🙈

I think it is hard to pinpoint exactly how to work with the Umbraco services and their scopes - this issue has some interesting reading though: https://github.com/umbraco/Umbraco-CMS/issues/14195

I'm not doing recursive work, actually. I'm doing 1. GetPagedOfType to get some content items 2. foreach item 3. Modify and publish the item if needed The recursive lock failure only appears when a different API controller is also doing the same as above, but not on the same content items. The above works fine as long as the sibling isn't doing stuff. That's why we only noticed this in production. So it seems like "under the hood" locks are taken and deemed to be recursive because of our code. But if CoreScoping this up solves the problem, I'm all for it. Based on our scenario and the error, do you think that's probable?

> Based on our scenario and the error, do you think that's probable? Not an expert.. try it out! 😅