Add IHostedLifecycleService

[steveharter]

Fixes#86511

Please see the "design notes" section in the linked issue above. Summary:

• Exception semantics are the same:
  • Exceptions are caught, logged, and then re-thrown
• Same guaranteed execution of callbacks
  • Callbacks will be called even if a prior phase had exceptions.
  • Exceptions from IHostApplicationLifetime are logged but do not re-throw.
• There is a "serial+concurrent" model for both new callbacks and the existing StartAsync\StopAsync when HostOptions.ServicesStartConcurrently and\or HostOptions.ServicesStopConcurrently are enabled.
• The new timeout for start is disabled by default.
• The new callbacks (Started, Stopping, Stopped) come before the corresponding IHostApplicationLifetime callbacks. The corresponding IHostLifetime callbacks (WaitForStartAsync and StopAsync) always come first\last.

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[ghost]

Tagging subscribers to this area: @dotnet/area-extensions-hosting
See info in area-owners.md if you want to be subscribed.

Issue Details

---

WIP

Author:	steveharter
Assignees:	steveharter
Labels:	area-Extensions-Hosting
Milestone:	-

[rafal-mz]

cool 😎

[Tratcher]

• That model is also applied to the existing StartAsync and\or StopAsync when HostOptions.ServicesStartConcurrently and\or HostOptions.ServicesStopConcurrently are enabled. Those options do not affect the new callbacks which always have the "serial+concurrent" semantics.

ServicesStartConcurrently and ServicesStopConcurrently should apply uniformly across events. Anything else is going to be extremely confusing. Especially since nobody even asked for ServicesStartConcurrently.

[steveharter]

ServicesStartConcurrently and ServicesStopConcurrently should apply uniformly across events. Anything else is going to be extremely confusing. Especially since nobody even asked for ServicesStartConcurrently.

That was the way it was prototyped originally, but later some of the scenarios were concurrent async validation - e.g. multiple validators (e.g. verifying certificates, endpoints, etc) or warm-up operations that are not related to each other which ideally run concurrently so the startup finishes sooner.

The default for ServicesStartConcurrently is false and changing to true may break backwards compat for existing implementations of StartAsync() especially for hosts that utilize StartAsync() for the long-running actual worker, so that may limit some scenarios that are controlled by a single knob.

If we go with ServicesStartConcurrently\ServicesStopConcurrently for the new events I suppose we could add knobs later (e.g. StartingIsConcurrent) to enable that per-event to enable that per event if necessary (instead of adding knobs later that would have the opposite defaults of ServicesStartConcurrently\ServicesStopConcurrently).

So I'm inclined now to change that behavior as suggested to help avoid confusion.

[steveharter]

/azp run runtime-libraries-coreclr outerloop-windows

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[buyaa-n]

LGTM

[steveharter]

Issues created for the long-running test failures (unrelated to this PR).

[steveharter]

Fixes#86511

Please see the "design notes" section in the linked issue above. Summary:

• Exception semantics are the same:
  • Exceptions are caught, logged, and then re-thrown
• Same guaranteed execution of callbacks
  • Callbacks will be called even if a prior phase had exceptions.
  • Exceptions from IHostApplicationLifetime are logged but do not re-throw.
• There is a "serial+concurrent" model for both new callbacks and the existing StartAsync\StopAsync when HostOptions.ServicesStartConcurrently and\or HostOptions.ServicesStopConcurrently are enabled.
• The new timeout for start is disabled by default.
• The new callbacks (Started, Stopping, Stopped) come before the corresponding IHostApplicationLifetime callbacks. The corresponding IHostLifetime callbacks (WaitForStartAsync and StopAsync) always come first\last.

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[ghost]

Tagging subscribers to this area: @dotnet/area-extensions-hosting
See info in area-owners.md if you want to be subscribed.

Issue Details

---

WIP

Author:	steveharter
Assignees:	steveharter
Labels:	area-Extensions-Hosting
Milestone:	-

[rafal-mz]

cool 😎

[Tratcher]

• That model is also applied to the existing StartAsync and\or StopAsync when HostOptions.ServicesStartConcurrently and\or HostOptions.ServicesStopConcurrently are enabled. Those options do not affect the new callbacks which always have the "serial+concurrent" semantics.

ServicesStartConcurrently and ServicesStopConcurrently should apply uniformly across events. Anything else is going to be extremely confusing. Especially since nobody even asked for ServicesStartConcurrently.

[steveharter]

ServicesStartConcurrently and ServicesStopConcurrently should apply uniformly across events. Anything else is going to be extremely confusing. Especially since nobody even asked for ServicesStartConcurrently.

That was the way it was prototyped originally, but later some of the scenarios were concurrent async validation - e.g. multiple validators (e.g. verifying certificates, endpoints, etc) or warm-up operations that are not related to each other which ideally run concurrently so the startup finishes sooner.

The default for ServicesStartConcurrently is false and changing to true may break backwards compat for existing implementations of StartAsync() especially for hosts that utilize StartAsync() for the long-running actual worker, so that may limit some scenarios that are controlled by a single knob.

If we go with ServicesStartConcurrently\ServicesStopConcurrently for the new events I suppose we could add knobs later (e.g. StartingIsConcurrent) to enable that per-event to enable that per event if necessary (instead of adding knobs later that would have the opposite defaults of ServicesStartConcurrently\ServicesStopConcurrently).

So I'm inclined now to change that behavior as suggested to help avoid confusion.

[steveharter]

/azp run runtime-libraries-coreclr outerloop-windows

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[buyaa-n]

LGTM

[steveharter]

Issues created for the long-running test failures (unrelated to this PR).

[steveharter]

Fixes#86511

Please see the "design notes" section in the linked issue above. Summary:

• Exception semantics are the same:
  • Exceptions are caught, logged, and then re-thrown
• Same guaranteed execution of callbacks
  • Callbacks will be called even if a prior phase had exceptions.
  • Exceptions from IHostApplicationLifetime are logged but do not re-throw.
• There is a "serial+concurrent" model for both new callbacks and the existing StartAsync\StopAsync when HostOptions.ServicesStartConcurrently and\or HostOptions.ServicesStopConcurrently are enabled.
• The new timeout for start is disabled by default.
• The new callbacks (Started, Stopping, Stopped) come before the corresponding IHostApplicationLifetime callbacks. The corresponding IHostLifetime callbacks (WaitForStartAsync and StopAsync) always come first\last.

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[ghost]

Tagging subscribers to this area: @dotnet/area-extensions-hosting
See info in area-owners.md if you want to be subscribed.

Issue Details

---

WIP

Author:	steveharter
Assignees:	steveharter
Labels:	area-Extensions-Hosting
Milestone:	-

[rafal-mz]

cool 😎

[Tratcher]

• That model is also applied to the existing StartAsync and\or StopAsync when HostOptions.ServicesStartConcurrently and\or HostOptions.ServicesStopConcurrently are enabled. Those options do not affect the new callbacks which always have the "serial+concurrent" semantics.

ServicesStartConcurrently and ServicesStopConcurrently should apply uniformly across events. Anything else is going to be extremely confusing. Especially since nobody even asked for ServicesStartConcurrently.

[steveharter]

ServicesStartConcurrently and ServicesStopConcurrently should apply uniformly across events. Anything else is going to be extremely confusing. Especially since nobody even asked for ServicesStartConcurrently.

That was the way it was prototyped originally, but later some of the scenarios were concurrent async validation - e.g. multiple validators (e.g. verifying certificates, endpoints, etc) or warm-up operations that are not related to each other which ideally run concurrently so the startup finishes sooner.

The default for ServicesStartConcurrently is false and changing to true may break backwards compat for existing implementations of StartAsync() especially for hosts that utilize StartAsync() for the long-running actual worker, so that may limit some scenarios that are controlled by a single knob.

If we go with ServicesStartConcurrently\ServicesStopConcurrently for the new events I suppose we could add knobs later (e.g. StartingIsConcurrent) to enable that per-event to enable that per event if necessary (instead of adding knobs later that would have the opposite defaults of ServicesStartConcurrently\ServicesStopConcurrently).

So I'm inclined now to change that behavior as suggested to help avoid confusion.

[steveharter]

/azp run runtime-libraries-coreclr outerloop-windows

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[buyaa-n]

LGTM

[steveharter]

Issues created for the long-running test failures (unrelated to this PR).

[steveharter]

Fixes#86511

Please see the "design notes" section in the linked issue above. Summary:

• Exception semantics are the same:
  • Exceptions are caught, logged, and then re-thrown
• Same guaranteed execution of callbacks
  • Callbacks will be called even if a prior phase had exceptions.
  • Exceptions from IHostApplicationLifetime are logged but do not re-throw.
• There is a "serial+concurrent" model for both new callbacks and the existing StartAsync\StopAsync when HostOptions.ServicesStartConcurrently and\or HostOptions.ServicesStopConcurrently are enabled.
• The new timeout for start is disabled by default.
• The new callbacks (Started, Stopping, Stopped) come before the corresponding IHostApplicationLifetime callbacks. The corresponding IHostLifetime callbacks (WaitForStartAsync and StopAsync) always come first\last.

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[ghost]

Tagging subscribers to this area: @dotnet/area-extensions-hosting
See info in area-owners.md if you want to be subscribed.

Issue Details

---

WIP

Author:	steveharter
Assignees:	steveharter
Labels:	area-Extensions-Hosting
Milestone:	-

[rafal-mz]

cool 😎

[Tratcher]

• That model is also applied to the existing StartAsync and\or StopAsync when HostOptions.ServicesStartConcurrently and\or HostOptions.ServicesStopConcurrently are enabled. Those options do not affect the new callbacks which always have the "serial+concurrent" semantics.

ServicesStartConcurrently and ServicesStopConcurrently should apply uniformly across events. Anything else is going to be extremely confusing. Especially since nobody even asked for ServicesStartConcurrently.

[steveharter]

ServicesStartConcurrently and ServicesStopConcurrently should apply uniformly across events. Anything else is going to be extremely confusing. Especially since nobody even asked for ServicesStartConcurrently.

That was the way it was prototyped originally, but later some of the scenarios were concurrent async validation - e.g. multiple validators (e.g. verifying certificates, endpoints, etc) or warm-up operations that are not related to each other which ideally run concurrently so the startup finishes sooner.

The default for ServicesStartConcurrently is false and changing to true may break backwards compat for existing implementations of StartAsync() especially for hosts that utilize StartAsync() for the long-running actual worker, so that may limit some scenarios that are controlled by a single knob.

If we go with ServicesStartConcurrently\ServicesStopConcurrently for the new events I suppose we could add knobs later (e.g. StartingIsConcurrent) to enable that per-event to enable that per event if necessary (instead of adding knobs later that would have the opposite defaults of ServicesStartConcurrently\ServicesStopConcurrently).

So I'm inclined now to change that behavior as suggested to help avoid confusion.

[steveharter]

/azp run runtime-libraries-coreclr outerloop-windows

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[buyaa-n]

LGTM

[steveharter]

Issues created for the long-running test failures (unrelated to this PR).

[steveharter]

Fixes#86511

Please see the "design notes" section in the linked issue above. Summary:

• Exception semantics are the same:
  • Exceptions are caught, logged, and then re-thrown
• Same guaranteed execution of callbacks
  • Callbacks will be called even if a prior phase had exceptions.
  • Exceptions from IHostApplicationLifetime are logged but do not re-throw.
• There is a "serial+concurrent" model for both new callbacks and the existing StartAsync\StopAsync when HostOptions.ServicesStartConcurrently and\or HostOptions.ServicesStopConcurrently are enabled.
• The new timeout for start is disabled by default.
• The new callbacks (Started, Stopping, Stopped) come before the corresponding IHostApplicationLifetime callbacks. The corresponding IHostLifetime callbacks (WaitForStartAsync and StopAsync) always come first\last.

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[ghost]

Tagging subscribers to this area: @dotnet/area-extensions-hosting
See info in area-owners.md if you want to be subscribed.

Issue Details

---

WIP

Author:	steveharter
Assignees:	steveharter
Labels:	area-Extensions-Hosting
Milestone:	-

[rafal-mz]

cool 😎

[Tratcher]

• That model is also applied to the existing StartAsync and\or StopAsync when HostOptions.ServicesStartConcurrently and\or HostOptions.ServicesStopConcurrently are enabled. Those options do not affect the new callbacks which always have the "serial+concurrent" semantics.

ServicesStartConcurrently and ServicesStopConcurrently should apply uniformly across events. Anything else is going to be extremely confusing. Especially since nobody even asked for ServicesStartConcurrently.

[steveharter]

ServicesStartConcurrently and ServicesStopConcurrently should apply uniformly across events. Anything else is going to be extremely confusing. Especially since nobody even asked for ServicesStartConcurrently.

That was the way it was prototyped originally, but later some of the scenarios were concurrent async validation - e.g. multiple validators (e.g. verifying certificates, endpoints, etc) or warm-up operations that are not related to each other which ideally run concurrently so the startup finishes sooner.

The default for ServicesStartConcurrently is false and changing to true may break backwards compat for existing implementations of StartAsync() especially for hosts that utilize StartAsync() for the long-running actual worker, so that may limit some scenarios that are controlled by a single knob.

If we go with ServicesStartConcurrently\ServicesStopConcurrently for the new events I suppose we could add knobs later (e.g. StartingIsConcurrent) to enable that per-event to enable that per event if necessary (instead of adding knobs later that would have the opposite defaults of ServicesStartConcurrently\ServicesStopConcurrently).

So I'm inclined now to change that behavior as suggested to help avoid confusion.

[steveharter]

/azp run runtime-libraries-coreclr outerloop-windows

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[buyaa-n]

LGTM

[steveharter]

Issues created for the long-running test failures (unrelated to this PR).

[steveharter]

Fixes#86511

Please see the "design notes" section in the linked issue above. Summary:

• Exception semantics are the same:
  • Exceptions are caught, logged, and then re-thrown
• Same guaranteed execution of callbacks
  • Callbacks will be called even if a prior phase had exceptions.
  • Exceptions from IHostApplicationLifetime are logged but do not re-throw.
• There is a "serial+concurrent" model for both new callbacks and the existing StartAsync\StopAsync when HostOptions.ServicesStartConcurrently and\or HostOptions.ServicesStopConcurrently are enabled.
• The new timeout for start is disabled by default.
• The new callbacks (Started, Stopping, Stopped) come before the corresponding IHostApplicationLifetime callbacks. The corresponding IHostLifetime callbacks (WaitForStartAsync and StopAsync) always come first\last.

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[ghost]

Tagging subscribers to this area: @dotnet/area-extensions-hosting
See info in area-owners.md if you want to be subscribed.

Issue Details

---

WIP

Author:	steveharter
Assignees:	steveharter
Labels:	area-Extensions-Hosting
Milestone:	-

[rafal-mz]

cool 😎

[Tratcher]

• That model is also applied to the existing StartAsync and\or StopAsync when HostOptions.ServicesStartConcurrently and\or HostOptions.ServicesStopConcurrently are enabled. Those options do not affect the new callbacks which always have the "serial+concurrent" semantics.

ServicesStartConcurrently and ServicesStopConcurrently should apply uniformly across events. Anything else is going to be extremely confusing. Especially since nobody even asked for ServicesStartConcurrently.

[steveharter]

ServicesStartConcurrently and ServicesStopConcurrently should apply uniformly across events. Anything else is going to be extremely confusing. Especially since nobody even asked for ServicesStartConcurrently.

That was the way it was prototyped originally, but later some of the scenarios were concurrent async validation - e.g. multiple validators (e.g. verifying certificates, endpoints, etc) or warm-up operations that are not related to each other which ideally run concurrently so the startup finishes sooner.

The default for ServicesStartConcurrently is false and changing to true may break backwards compat for existing implementations of StartAsync() especially for hosts that utilize StartAsync() for the long-running actual worker, so that may limit some scenarios that are controlled by a single knob.

If we go with ServicesStartConcurrently\ServicesStopConcurrently for the new events I suppose we could add knobs later (e.g. StartingIsConcurrent) to enable that per-event to enable that per event if necessary (instead of adding knobs later that would have the opposite defaults of ServicesStartConcurrently\ServicesStopConcurrently).

So I'm inclined now to change that behavior as suggested to help avoid confusion.

[steveharter]

/azp run runtime-libraries-coreclr outerloop-windows

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[buyaa-n]

LGTM

[steveharter]

Issues created for the long-running test failures (unrelated to this PR).

[steveharter]

Fixes#86511

Please see the "design notes" section in the linked issue above. Summary:

• Exception semantics are the same:
  • Exceptions are caught, logged, and then re-thrown
• Same guaranteed execution of callbacks
  • Callbacks will be called even if a prior phase had exceptions.
  • Exceptions from IHostApplicationLifetime are logged but do not re-throw.
• There is a "serial+concurrent" model for both new callbacks and the existing StartAsync\StopAsync when HostOptions.ServicesStartConcurrently and\or HostOptions.ServicesStopConcurrently are enabled.
• The new timeout for start is disabled by default.
• The new callbacks (Started, Stopping, Stopped) come before the corresponding IHostApplicationLifetime callbacks. The corresponding IHostLifetime callbacks (WaitForStartAsync and StopAsync) always come first\last.

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[ghost]

Tagging subscribers to this area: @dotnet/area-extensions-hosting
See info in area-owners.md if you want to be subscribed.

Issue Details

---

WIP

Author:	steveharter
Assignees:	steveharter
Labels:	area-Extensions-Hosting
Milestone:	-

[rafal-mz]

cool 😎

[Tratcher]

• That model is also applied to the existing StartAsync and\or StopAsync when HostOptions.ServicesStartConcurrently and\or HostOptions.ServicesStopConcurrently are enabled. Those options do not affect the new callbacks which always have the "serial+concurrent" semantics.

ServicesStartConcurrently and ServicesStopConcurrently should apply uniformly across events. Anything else is going to be extremely confusing. Especially since nobody even asked for ServicesStartConcurrently.

[steveharter]

ServicesStartConcurrently and ServicesStopConcurrently should apply uniformly across events. Anything else is going to be extremely confusing. Especially since nobody even asked for ServicesStartConcurrently.

That was the way it was prototyped originally, but later some of the scenarios were concurrent async validation - e.g. multiple validators (e.g. verifying certificates, endpoints, etc) or warm-up operations that are not related to each other which ideally run concurrently so the startup finishes sooner.

The default for ServicesStartConcurrently is false and changing to true may break backwards compat for existing implementations of StartAsync() especially for hosts that utilize StartAsync() for the long-running actual worker, so that may limit some scenarios that are controlled by a single knob.

If we go with ServicesStartConcurrently\ServicesStopConcurrently for the new events I suppose we could add knobs later (e.g. StartingIsConcurrent) to enable that per-event to enable that per event if necessary (instead of adding knobs later that would have the opposite defaults of ServicesStartConcurrently\ServicesStopConcurrently).

So I'm inclined now to change that behavior as suggested to help avoid confusion.

[steveharter]

/azp run runtime-libraries-coreclr outerloop-windows

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[buyaa-n]

LGTM

[steveharter]

Issues created for the long-running test failures (unrelated to this PR).

[steveharter]

Fixes#86511

Please see the "design notes" section in the linked issue above. Summary:

• Exception semantics are the same:
  • Exceptions are caught, logged, and then re-thrown
• Same guaranteed execution of callbacks
  • Callbacks will be called even if a prior phase had exceptions.
  • Exceptions from IHostApplicationLifetime are logged but do not re-throw.
• There is a "serial+concurrent" model for both new callbacks and the existing StartAsync\StopAsync when HostOptions.ServicesStartConcurrently and\or HostOptions.ServicesStopConcurrently are enabled.
• The new timeout for start is disabled by default.
• The new callbacks (Started, Stopping, Stopped) come before the corresponding IHostApplicationLifetime callbacks. The corresponding IHostLifetime callbacks (WaitForStartAsync and StopAsync) always come first\last.

[ghost]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[ghost]

Tagging subscribers to this area: @dotnet/area-extensions-hosting
See info in area-owners.md if you want to be subscribed.

Issue Details

---

WIP

Author:	steveharter
Assignees:	steveharter
Labels:	area-Extensions-Hosting
Milestone:	-

[rafal-mz]

cool 😎

[Tratcher]

• That model is also applied to the existing StartAsync and\or StopAsync when HostOptions.ServicesStartConcurrently and\or HostOptions.ServicesStopConcurrently are enabled. Those options do not affect the new callbacks which always have the "serial+concurrent" semantics.

ServicesStartConcurrently and ServicesStopConcurrently should apply uniformly across events. Anything else is going to be extremely confusing. Especially since nobody even asked for ServicesStartConcurrently.

[steveharter]

ServicesStartConcurrently and ServicesStopConcurrently should apply uniformly across events. Anything else is going to be extremely confusing. Especially since nobody even asked for ServicesStartConcurrently.

That was the way it was prototyped originally, but later some of the scenarios were concurrent async validation - e.g. multiple validators (e.g. verifying certificates, endpoints, etc) or warm-up operations that are not related to each other which ideally run concurrently so the startup finishes sooner.

The default for ServicesStartConcurrently is false and changing to true may break backwards compat for existing implementations of StartAsync() especially for hosts that utilize StartAsync() for the long-running actual worker, so that may limit some scenarios that are controlled by a single knob.

If we go with ServicesStartConcurrently\ServicesStopConcurrently for the new events I suppose we could add knobs later (e.g. StartingIsConcurrent) to enable that per-event to enable that per event if necessary (instead of adding knobs later that would have the opposite defaults of ServicesStartConcurrently\ServicesStopConcurrently).

So I'm inclined now to change that behavior as suggested to help avoid confusion.

[steveharter]

/azp run runtime-libraries-coreclr outerloop-windows

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[buyaa-n]

LGTM

[steveharter]

Issues created for the long-running test failures (unrelated to this PR).