Bogdan Drutu

Why is the exporter than. I 100% agree with you for consistency, but still not seeing usefulness for exporter either.

> It allows us to start the Collector only running extensions. This is useful for the bootstrapping process done by the OpAMP Supervisor. For this an alternative is very simple...

> What problem is being solved by removing it? There are multiple problems: 1. We are adding the notion of "extension" within the component package which should be agnostic of...

> component is not agnostic to component types: we define [component.Kind](https://pkg.go.dev/go.opentelemetry.io/collector/component#Kind). I think now component type can be in service?

>In the case where origErr does contain conflicting information (e.g. a nested status.Status) assume the caller has the most relevant context and use the provided HTTP/gRPC status code. if the...

>As for using errors.As, if I understand you correctly, even if the error is both, I expect callers will check for consumererror.Error first and status.Status second, in which case there...

>This will still return an error. We need to develop this further, but the goal for now is that it is up to the caller to determine whether they want...

>I still don't expect anyone to go out of their way to use a 200 error code here, but I don't want to be prescriptive until we've decided on how...

>I don't think we can remove it until https://github.com/open-telemetry/opentelemetry-collector/issues/12879 is resolved These are different issues. the deprecated config also does not support "request" batching. See https://github.com/open-telemetry/opentelemetry-collector/pull/13003/files#diff-45d09df1b12e28cfc26a0bc617f391a559334fed9a5df242fd179ad5e85fe3e0L141

Since this is "experimental" feature, still not sure we should block this... but for the moment, if in this version we don't have a solution for your problem @dmitryax I...