You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The OTLP Exporter crate defines a public Error enum that is currently accessible throughout the crate and to external consumers. The processor, however, interacts with these errors through the ExportError trait, which abstracts away the specific details of the underlying Error enum.
Should the Error enum and its variants remain public, given that they are primarily relevant to the OTLP Exporter crate itself?
Is there a use case for the processor or other consumers to directly match on or handle specific variants of the Error enum, or is the abstraction provided by ExportError sufficient?
Does the processor need to take any action based on specific OTLP Error enum variants?
Should the processor be designed to react differently to specific errors (e.g., transport errors, invalid URIs, etc.), or does it suffice to treat all exporter errors uniformly?
In the current design, the processor wraps errors using LogError::ExportFailed, which stores a boxed ExportError:
LogError::ExportFailed(Box<dyn ExportError>)
To handle specific OTLP Error variants, the consumer(i.e, processor) must perform a manual downcast:
The text was updated successfully, but these errors were encountered:
lalitb
changed the title
Should OTLP Exporter Error Enum Be Public and Visible to the Processor?
Should OTLP Exporter Error enum be public and visible to the processor?
Jan 24, 2025
My thoughts:
No need of exposing specific error codes from OTLP. It should do internal logging with details of the error, and then propagate ExportError enum back to processor.
ExportError can have timeout(Duration),Other(String) and maybe AlreadyShutdown()
More for discussion.
The OTLP Exporter crate defines a public Error enum that is currently accessible throughout the crate and to external consumers. The processor, however, interacts with these errors through the ExportError trait, which abstracts away the specific details of the underlying Error enum.
Error
enum and its variants remain public, given that they are primarily relevant to the OTLP Exporter crate itself?In the current design, the processor wraps errors using
LogError::ExportFailed
, which stores a boxedExportError
:To handle specific OTLP Error variants, the consumer(i.e, processor) must perform a manual downcast:
However, in that case, processor should handle such downcast and error handling for all other exporters (if they have any such error enum).
cc @scottgerring , @cijothomas
The text was updated successfully, but these errors were encountered: