Matthew Wear

I'll propose an alternative to the guidelines I previously mentioned. The previous proposal is still on the table, as well any other alternatives anyone wants to propose. For this alternative,...

> I think my one fear with the alternative proposal is that it would allow a collector to start with all components experiencing StatusPermanentError, resulting in 0 components in StatusOK...

I'm ultimately ok with allowing `Start` to have a fail fast mechanism. My suggestion to consider removing it, was to simplify the distinction between a `PermanentError` and `FatalError`, and error...

After thinking about this a little more, I think we can retain the behavior of the previous proposal and simplify how errors are be handled during start. I suggest that...

There are two issues with this proposal. One is that `FatalError`s can happen as a result of `Start`, but not necessarily by the time `Start` returns. This is discussed a...

Similar discussions have come up here: https://github.com/open-telemetry/opentelemetry-js/issues/852.

If I were only reporting status for exporters, I would choose #8684 because it introduces a flexible opt-in approach that reduces the overall amount of code that needs to be...

Once we are happy with the aggregation for the health check extension, I think we can and should promote it to core, or some other shared library. We may have...

There are two behaviors related to status reporting that were implemented in `sharedcomponent` that need to be preserved in this PR. A shared component represents multiple, logical component instances as...

The intent of having a permanent error state is to allow the collector to run in a degraded mode, and communicate issues to operators through the health check extension or...