I have a hangfire task that loops through a bunch of data from an API, uses it to either Save, Save & Publish or Unpublish multiple content items. The ContentService itself seesm to be working as expected and is able to update each bit of content correctly, but I'm seeing the following error somewhat sporadically.

prolog
[12:30:03 ERR] Error occurred executing workItem.
System.AggregateException: One or more errors occurred. (No AmbientContext was found.)
 ---> System.InvalidOperationException: No AmbientContext was found.
   at Umbraco.Cms.Infrastructure.Scoping.AmbientScopeContextStack.Pop()
   at Umbraco.Cms.Infrastructure.Scoping.ScopeProvider.PopAmbientScopeContext()
   at Umbraco.Cms.Infrastructure.Scoping.Scope.<>c__DisplayClass56_0.<RobustExit>g__HandleScopeContext|0()
   at Umbraco.Cms.Infrastructure.Scoping.Scope.TryFinally(Action[] actions)
   --- End of inner exception stack trace ---
   at Umbraco.Cms.Infrastructure.Scoping.Scope.TryFinally(Action[] actions)
   at Umbraco.Cms.Infrastructure.Scoping.Scope.RobustExit(Boolean completed, Boolean onException)
   at Umbraco.Cms.Infrastructure.Scoping.Scope.DisposeLastScope()
   at Umbraco.Cms.Infrastructure.Scoping.Scope.Dispose()
   at Umbraco.Cms.Infrastructure.Examine.ExamineUmbracoIndexingHandler.DeferredReIndexForContent.<>c__DisplayClass6_0.<Execute>b__0(CancellationToken cancellationToken)
   at Umbraco.Cms.Infrastructure.HostedServices.QueuedHostedService.BackgroundProcessing(CancellationToken stoppingToken)

This error seems to occur more frequently on the first run, then less so afterwards, although it does still happen. For context, it's currently updated around 20 content items.

Have a read of this from the v8 days - https://our.umbraco.com/forum/using-umbraco-and-getting-started/102676-triggering-index-rebuild-via-hangfire-causes-objectdisposedexception-in-nucache I "think" this is still relevant in .Net core

Hmm I'm using the following before my bit of code before using the IContentService etc, which looks to be what Shannon suggests, along with some suggestions from @User etc

cs
using var backgroundScope = new BackgroundScope(_serverMessenger);
using var umbracoContext = _contextFactory.EnsureUmbracoContext();
using var serviceScope = _serviceProvider.CreateScope();

Stupid question, but can you verify that indexing failures occur when saving this way? If it's just a timing problem in the Examine/Scope teardown, maybe there's no real problem?

Hmmm, it may be a bit of a red herring, although we did get a database write lock at one point and it looks like it may have been related. That being said, it could have just been a random lost connection that locked the db, although i feel like that shouldn't happen so easily

public class BackgroundScope : IBackgroundScope { private readonly IServerMessenger _serverMessenger; public BackgroundScope(IServerMessenger serverMessenger) { _serverMessenger = serverMessenger; } public void Dispose() { if (_serverMessenger is BatchedDatabaseServerMessenger batchedDatabaseServerMessenger) { batchedDatabaseServerMessenger.SendMessages(); } } }

Yeah, i've got this set up as well

an older thread, but I thought it might be a good to add this here, as I've not exactly seen this solution anywhere, but pieces of it has been available here and there. 🙂 Long story short, we had similar issues, but had a wide variety of hangfire jobs in our solution, and they started to give similar errors and the issues described here as well: https://our.umbraco.com/forum/using-umbraco-and-getting-started/113065-the-scope-being-disposed-is-not-the-ambient-scope An example of a hangfire task that we are currently using:

csharp
public async Task Run(PerformContext? performContext, CancellationToken cancellationToken)
{
    performContext.WriteLine("Starting the process");

    Task someWorkTask;
    
    using (ExecutionContext.SuppressFlow())
    {
        someWorkTask = Task.Run(async () =>
        {
            await _someService.SomeWorkAsync();
        }, cancellationToken);
    }

    await someWorkTask;

    performContext.WriteLine("Finishing the process");
}

the PerformContext is not super important obviously, but the position if the someWorkTask awaiting it is, otherwise hangfire would just fire and forget, but you'd have no control over it. It is quite a recent change, but it is in production now for a week, and we've not seen the scope issues since. Everything the others has written above also stands and we are also using them (BackgroundScope, contextfactory, serviceprovider etc.)

Very interesting, thanks!