-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[chore] [exporterhelper] Remove retry sender -> queue sender callback #8985
[chore] [exporterhelper] Remove retry sender -> queue sender callback #8985
Conversation
c191421
to
70df458
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #8985 +/- ##
==========================================
- Coverage 91.55% 91.55% -0.01%
==========================================
Files 315 315
Lines 17117 17113 -4
==========================================
- Hits 15672 15668 -4
Misses 1150 1150
Partials 295 295 ☔ View full report in Codecov by Sentry. |
70df458
to
6895ec1
Compare
Use returned error instead to simplify the senders feedback loop. This change preserves the behavior. Re-enqueueing of the temporary failures depend on enabled retry sender. This will be changed in the next step when re-queueing becomes a configurable option
6895ec1
to
80531cc
Compare
// If retry sender is disabled then disable requeuing in the queue sender. | ||
// TODO: Make re-enqueuing configurable on queue sender instead of relying on retry sender. | ||
if qs, ok := be.queueSender.(*queueSender); ok { | ||
// if it's not retrySender, then it is disabled. | ||
if _, ok = be.retrySender.(*retrySender); !ok { | ||
qs.requeuingEnabled = false | ||
} | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure that this was intentional or a bug of the previous implementation. Happy to keep it as it is now, but my bet is that it was just a bug in the previous implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even if it's a bug, I believe some users may rely on this behavior. Fixing it right away by removing the dependency would be a breaking change for those who don't want re-enqueueing in the persistent queue. I submitted an issue to introduce an explicit option to control it #8987. Will handle it next
After open-telemetry#8985, the whole request is requeued even with the partial request error. This change fixes it and restores the previous behavior. No changelog is needed since the bug is not released yet.
…open-telemetry#8985) Use returned error instead to simplify the senders feedback loop. This change preserves the behavior. Re-enqueueing of the temporary failures depends on the enabled retry sender. This will be changed in the next step when re-queueing becomes a configurable option
…pen-telemetry#8992) After open-telemetry#8985, the whole request is requeued even with the partial request error. This change fixes it and restores the previous behavior. No changelog is needed since the bug is not released yet.
Use returned error instead to simplify the senders feedback loop. This change preserves the behavior. Re-enqueueing of the temporary failures depends on the enabled retry sender. This will be changed in the next step when re-queueing becomes a configurable option