[consumererror] Add OTLP-centric error type #13042
Conversation
evan-bradley
requested review from
mx-psi,
bogdandrutu,
jmacd,
dmitryax and
TylerHelmuth
Codecov ReportAttention: Patch coverage is
❌ Your patch check has failed because the patch coverage (91.39%) is below the target coverage (95.00%). You can increase the patch coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## main #13042 +/- ##
==========================================
- Coverage 91.27% 91.27% -0.01%
==========================================
Files 510 512 +2
Lines 28758 28848 +90
==========================================
+ Hits 26250 26332 +82
- Misses 1993 2001 +8
Partials 515 515 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
I'll look at improving the code coverage tomorrow. In the meantime, this should be in a pretty good state. |
|
The remaining functions missing test coverage are the status code conversion functions, which are pretty direct. I don't think tests are very helpful since the functions are pretty direct mappings. The only thing I can think of that would meaningfully improve coverage is to store the mappings in a map object as opposed to in a switch statement, but feels like a slightly worse implementation. |
|
Since this was specially controversial last time, I suggest we wait either until we have more approvals (I suggest 4) or some time has passed (I would suggest Friday next week). cc @open-telemetry/collector-approvers |
There was a problem hiding this comment.
Really good to see this moving forward. This looks the way I would expect it to look after reviewing earlier feedback from @bogdandrutu.
There was a problem hiding this comment.
There is a big problem we identified in the past, which is that the default behavior of the errors in the collector pipelines is that they are retryable. It seems that this PR changes that, which I 1000% support, but we need to make sure we document this change and analyze the impact of that.
Agreed. That will come in a follow-up once we start to use this, I will make sure we proceed discerningly here. |
consumer/consumererror/error.go
Outdated
| // See https://github.com/open-telemetry/opentelemetry-proto/blob/main/docs/specification.md for more details. | ||
| // | ||
| // If a gRPC code cannot be derived from these three sources then INTERNAL is returned. | ||
| func (e *Error) OTLPGRPCStatus() *status.Status { |
There was a problem hiding this comment.
I would actually change the signature to something like:
func ToGRPCStatus(e error) *status.Status;
This way:
- Can handle the "error.As" part.
- Can handle extra details like retry-after you proposed with the constructor.
There was a problem hiding this comment.
That makes sense to me. Receivers will find a function like this very ergonomic if they're only concerned about transmitting the original status code, and we can always duplicate the functionality in a method later. Added.
|
|
||
| // NewOTLPGRPCError records a gRPC status code that was received from a server | ||
| // during data submission. | ||
| func NewOTLPGRPCError(origErr error, status *status.Status) error { |
There was a problem hiding this comment.
Is there an "original" error in this case?
There was a problem hiding this comment.
There is, you can see an example from the OTLP exporter here.
I'd like to continue to wrap downstream errors even if calls to NewOTLPGRPCError will generally be made in exporters. We could call status.FromError in this function, but then we end up in the awkward case where the code in the *status.Status object is okay and there's no easy way in the exporter to tell it wasn't an error. As a result I think the best we can do is just accept both, even if it makes the function signature slightly awkward.
There's some symmetry with the function signature for NewOTLPHTTPError, which I think makes up for it a bit.
Description
Continuation of #11085.
Link to tracking issue
Fixes #7047