As part of #87335 and #88546 we should evaluate the current exception handling abort semantics between the stages which is currently:

• An exception in any handlers of Starting, Start and Started do not prevent the next stage from running.
  • Exceptions are gathered, the next stage is run and after Started is run, an exception is thrown and IHostApplicationLifetime.ApplicationStarted is not called.
• Within each stage, if an exception is thrown:
  • If non-concurrent, the rest of the stage is cancelled.
  • If concurrent, the rest of the stage continues (since they are all run concurrently). Note that concurrent mode is new for v8.
  • These semantics were not changed with the above PRs.

For the current implementation, see StartAsync() here.

Proposal: If there is an exception in Starting, Start or Started, processing stops and the next stage is not run. The exception is logged and re-thrown. For Started, if there is an exception then IHostApplicationLifetime.ApplicationStarted is not run which is consistent with the prior behavior (before the new stages were added in #87335) if there was an exception in Start.

Note that for Stopping\Stop\Stopped, it makes sense to continue to run each phase so that the proper clean-up work is handled, so this does not have the same semantics as Starting\Start\Starting. As a side note, we should verify when ASP.NET calls StopAsync() if there is an exception in StartAsync().