Ensure BackgroundService invokes ExecuteAsync after start

[steveisok]

Fixes#131249.

BackgroundService.StartAsync currently passes its stopping token to Task.Run as the scheduling token. If StopAsync or Dispose cancels that token before the queued delegate begins, the task transitions to Canceled without invoking ExecuteAsync.

This makes invocation timing-dependent: after a non-canceled start is accepted, ExecuteAsync may or may not run depending on whether the thread pool dequeues it before cancellation.

This change:

• Preserves the .NET 10 change that all ExecuteAsync work runs asynchronously on a thread-pool thread.
• Makes invocation deterministic after a non-canceled start is accepted by using CancellationToken.None as the Task.Run scheduling token.
• Passes the linked stopping token to ExecuteAsync, so an immediate stop or dispose invokes it with cancellation already requested.
• Preserves pre-canceled StartAsync behavior by explicitly assigning Task.FromCanceled(cancellationToken) to ExecuteTask without invoking ExecuteAsync.

Regression tests deterministically occupy the sole thread-pool worker and verify that immediate stop and dispose still invoke ExecuteAsync exactly once on a thread-pool thread with an already-canceled stopping token. Pre-canceled startup coverage verifies that ExecuteTask is canceled and ExecuteAsync is not invoked.

Note

This pull request description was generated with GitHub Copilot.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[steveisok]

@jeffhandley deferring to you on who best to review.

[Copilot]

Pull request overview

This PR adjusts BackgroundService.StartAsync scheduling so that ExecuteAsync is still invoked even if the service is stopped/disposed immediately after start, and adds regression coverage to validate the behavior under deterministic thread-pool starvation.

Changes:

• Update BackgroundService.StartAsync to avoid using the stopping token as the Task.Run scheduling token.
• Add a regression test that blocks the sole thread-pool worker and verifies ExecuteAsync still runs exactly once when immediately stopped/disposed.
• Update the pre-canceled StartAsync test to assert ExecuteTask is canceled and ExecuteAsync is not invoked.

Show a summary per file

File	Description
src/libraries/Microsoft.Extensions.Hosting.Abstractions/src/BackgroundService.cs	Changes how ExecuteAsync is scheduled/canceled to prevent cancellation from suppressing delegate invocation.
src/libraries/Microsoft.Extensions.Hosting/tests/UnitTests/BackgroundServiceTests.cs	Adds deterministic regression coverage for immediate stop/dispose and refines pre-canceled start assertions.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 2
• Review effort level: Lite

[Copilot]

Review details

Suppressed comments (2)

src/libraries/Microsoft.Extensions.Hosting/tests/UnitTests/BackgroundServiceTests.cs:203

• ExecuteInvocation.GetResult() has no timeout, so if ExecuteAsync is never invoked this test will hang the RemoteExecutor process rather than failing with an assertion. Add a bounded wait (reusing RemoteExecutor.FailWaitTimeoutMilliseconds) before reading the result.

 (int invocationCount, int threadId, bool isThreadPoolThread, bool isCancellationRequested) =
service.ExecuteInvocation.GetAwaiter().GetResult();
Assert.Equal(1, invocationCount);

src/libraries/Microsoft.Extensions.Hosting/tests/UnitTests/BackgroundServiceTests.cs:163

• The RemoteExecutor child process can hang indefinitely if the regression is reintroduced (or if the child process stalls). Similar tests in this repo set RemoteInvokeOptions.TimeOut so a hang fails fast and doesn't consume the full harness timeout.

This issue also appears on line 201 of the same file.

 var options = new RemoteInvokeOptions();
options.StartInfo.EnvironmentVariables["DOTNET_ThreadPool_UseWindowsThreadPool"] = "0";

• Files reviewed: 2/2 changed files
• Comments generated: 0 new
• Review effort level: Lite

[rosebyte]

I'm not sure I follow the wording about preserving .NET 10 behaviour. Do you mean that this preserves only the .NET 10 change whereby all ExecuteAsync work runs asynchronously on a thread-pool thread? As I understand the file history, invocation itself has had three different behaviours:

1. Before .NET 10, ExecuteAsync was called regardless of whether the cancellation token was already cancelled.

2. In .NET 10, whether ExecuteAsync is called effectively depends on whether the scheduler wins the race with cancellation.

3. With this PR, ExecuteAsync is called if and only if the cancellation token has not already been cancelled when StartAsync checks it.

The PR makes sense to me, and I consider the resulting behaviour clearly superior, so I'm going to approve it. I only wonder if I miss anything in the PR descriptiion.

[steveisok]

@rosebyte before moving this forward I want to bring #131249 (comment) here. He's got a fair concern and there is a trade-off we are making as a result of the PR. We are trading “sometimes silently never invoke the service” for "always invoke it, requiring the service to honor an already-canceled token.”.

Thoughts on what you think is best?

[rosebyte]

Passing stoppingToken to Task.Run does not guarantee that ExecuteAsync will not be invoked after cancellation, because the delegate may win the race. ExecuteAsync must therefore handle an already cancelled token anyway. Using that token as a scheduler gate merely adds a timing-dependent outcome where ExecuteAsync is never invoked. CancellationToken.None removes that ambiguity and avoids the small overhead of registering cancellation with the scheduled task.

[steveisok]

/ba-g Known issue #132336

[steveisok]

/backport to release/11.0-rc1

[github-actions]

Started backporting to release/11.0-rc1 (link to workflow run)