perhaps let it write to log each x min to test it

So I added the Period to the logger, let it run for a couple of cycles on 2 mins, changed it to 3 mins and let it run on a few more. As you can see from the output below, even though it picked up the Period change, it still ran on 2 minute updates! [13:27:11 INF] PDF folder checked: was empty. [13:27:11 INF] PDF folder checked: Period: 00:02:00 [13:29:11 INF] PDF folder checked: was empty. [13:29:11 INF] PDF folder checked: Period: 00:02:00 [13:29:52 INF] Document Site Settings (id=1069) has been published. (change to 3 mins here) [13:29:52 INF] Adding examine event handlers for 4 index providers. [13:31:11 INF] PDF folder checked: was empty. [13:31:11 INF] PDF folder checked: Period: 00:02:00 [13:33:11 INF] PDF folder checked: was empty. [13:33:11 INF] PDF folder checked: Period: 00:03:00 [13:35:11 INF] PDF folder checked: was empty. [13:35:11 INF] PDF folder checked: Period: 00:03:00 I use a function to get the time from the back office. But it's reading the cache, should it be using the content service instead? I'm thinking the cache might not be updated till the page is called.

private int GetTime() {
        using var context = _contextFactory.EnsureUmbracoContext();
        if (context.UmbracoContext.Content == null) {
            throw new InvalidOperationException("Application can't access nucache...");
        }

        var siteSettings = context.UmbracoContext.Content.GetAtRoot().First().FirstChild<SiteSettings>();
        int scheduledTimePeriod = siteSettings?.PDfclearanceSchedule ?? 3;
           
        return scheduledTimePeriod;
    }

but the change has to happen in the processing, you can't change the time outside of the process. because they way it works internally, is it executes the process then sets the timer to fire for next time, if you change the time outside of that loop, it doesn't change the existingf timer to fire anytime sooner.

if you want your background task to run 'now' then you are probibly better queuing the bacground task on the background TaskQueue. e.g

cs
_backgroundTaskQueue.QueueBackgroundWorkItem(
    cancellationToken => Task.Run(() =>
    {    _backgroundService.ProcessQueueItem(notification.QueuedItem.Key);
    }, cancellationToken));

if you do this, then you need to put some guard in place for the background recurring task and the thing you have put into a background thread running at the same time. A semaphore is usually the way to go.

cs
 if (await _processingSemaphore.WaitAsync(TimeSpan.FromMinutes(_waitTime)))
 {
     try
     {
         // do the things you need here.
     }
     catch (Exception ex)
     {
         _logger.LogError(ex, "Error")
     }
     finally
     {
         _processingSemaphore.Release();
     }
 }

So as you might be able to tell here, i have a

backgroundHostedService

and a

backgroundService

all the work goes on in the backgroundService the backgroundHostedService is calling it from it's own PerformExecuteAsync method, but also because all the work and guards are in the backgroundservice i can put it on a background thread, and be OK that they won't clash.