fix(kafkareceiver): enforce a backoff mechanism on exporterhelper.ErrQueueIsFull error

[an-mmx]

Description

In the current implementation, the BackOff mechanism is trigerred only by memory limiter error. However, the same behavior is expected for the exporterhelper.ErrQueueIsFull error, which occurs when there is a sending queue overflow (both memory queue and persistent queue).

Link to tracking issue

#39580

Testing

Unit coverage added

Documentation

No documentation updated

[MovieStoreGuy]

Please also resolve the conflicts.

[MovieStoreGuy]

Can this used either errors.Is or errors.As instead of comparing the strings?

[an-mmx]

Unfortunately, I don't see how this can be utilized without changes in opentelemetry-collector, since the memory limiter error is in an internal package: https://github.com/open-telemetry/opentelemetry-collector/blob/main/internal/memorylimiter/memorylimiter.go#L28

[atoulme]

Moving to draft while this is being worked on

[axw]

@an-mmx did you consider updating the logic to retry on any error that is not considered permanent, like the exporterhelper retry sender? https://github.com/open-telemetry/opentelemetry-collector/blob/d020c9074f873c54e8ae7b8eaa4a08e13157cb76/exporter/exporterhelper/internal/retry_sender.go#L96-L99

I think that would be the ideal solution

[an-mmx]

@an-mmx did you consider updating the logic to retry on any error that is not considered permanent, like the exporterhelper retry sender? https://github.com/open-telemetry/opentelemetry-collector/blob/d020c9074f873c54e8ae7b8eaa4a08e13157cb76/exporter/exporterhelper/internal/retry_sender.go#L96-L99

I think that would be the ideal solution

I hadn’t considered this approach before.
It sounds reasonable, and I don’t see any negative side effects so far. If there are no objections from the codeowners, I’m okay with modifying this change in the proposed way.