Span::End() api should return failure if export fails

[VivekSubr]

Is your feature request related to a problem?
We've seen intermittent export failures in our setup at high load, but since Span::End() gives no indication of failure, it's hard to keep track of them.

Describe the solution you'd like
Span::End should return a return code, with failure reason

Describe alternatives you've considered
Doesn't seem to be any other way for app to keep track of export failures.

[lalitb]

Any errors encountered during export should be logged using the global log handler. If this is not occurring in a specific export scenario, it should be corrected. By default, the handler logs to stderr, but users can configure their own custom handler.

However, Span::End() should not return a status. Once a span is ended, it becomes immutable, and the instrumented library cannot act on export failures. Error logging and handling are the responsibility of the application using the OpenTelemetry SDK, not the instrumented library.

[VivekSubr]

@lalitb - How can application handle export failures? Are they any examples?

[lalitb]

See if this helps - https://github.com/open-telemetry/opentelemetry-cpp/blob/v1.18.0/functional/otlp/func_http_main.cc

The functional test is setting custom handler -

opentelemetry-cpp/functional/otlp/func_http_main.cc

Line 493 in 955a807

internal_log::GlobalLogHandler::SetLogHandler(log_handler);

to validate the errors.

[lalitb]

@VivekSubr Do you have further concerns, or this can be closed?

[VivekSubr]

Well, I feel the log handler is not a good place for app to do things like retry export or increment a metric, but if that's the position of the project, sure.

[lalitb]

Well, I feel the log handler is not a good place for app to do things like retry export or increment a metric,

Both log-handler and app are not the good place to do retry in case of export failure. The exports are asynchronous (in case of batch processor), and it is not feasible for the application to get the status of the exports and retry. The retry should be implemented by the exporter ( as documented in the OTLP exporter specs - OTLP retry ). Unfortunately otel-cpp OTLP exporter doesn't support retry (though contribution are welcome to add the support).