Add force_flush to LogExporter #2276
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2276 +/- ##
=======================================
- Coverage 79.5% 79.5% -0.1%
=======================================
Files 123 123
Lines 21492 21514 +22
=======================================
+ Hits 17094 17111 +17
- Misses 4398 4403 +5 ☔ View full report in Codecov by Sentry. |
| /// implemented as a blocking API or an asynchronous API which notifies the caller via | ||
| /// a callback or an event. OpenTelemetry client authors can decide if they want to | ||
| /// make the flush timeout configurable. | ||
| fn force_flush(&mut self) -> BoxFuture<'static, ExportResult> { |
There was a problem hiding this comment.
should we instead have async fn force_flush(&mut self) -> ExportResult - it's more cleaner, without boxing overhead
There was a problem hiding this comment.
Updated it to be async.
|
Can we also add a unit-test for batch processor, with mock-exporter, to validate that the exporter's force flush get's called. |
|
We may need to add both sync and async versions for provider / processors and exporter for shutdown() and force_flush(), and so different pipelines based on what is invoked. I am looking into those aspects, but this PR change would be still required. @cijothomas @utpilla @TommyCpp if anyone has concern here. |
| /// such as when using some FaaS providers that may suspend the process after | ||
| /// an invocation, but before the exporter exports the completed logs. | ||
| /// | ||
| /// This function SHOULD complete or abort within some timeout. This function can be |
There was a problem hiding this comment.
Let's update the comments here to reflect the actual trait method definition instead of putting the spec guidelines for this method.
We could put something like:
/// This method will block the current thread until all pending log records are exported. If the export was not
/// successful, an error is returned.
| /// a callback or an event. OpenTelemetry client authors can decide if they want to | ||
| /// make the flush timeout configurable. | ||
| fn force_flush(&mut self) -> ExportResult { | ||
| Ok(()) |
There was a problem hiding this comment.
I think we should not have a default implementation for this method. Otherwise, we could run into a situation where an exporter user goes through the documentation and calls force_flush with certain expectations that haven't been agreed upon by the exporter author.
It looks like we have a default implementation for a few other methods as well such as shutdown and set_resource. We should revisit them based on what we decide.
| @@ -278,7 +282,8 @@ impl<R: RuntimeChannel> BatchLogProcessor<R> { | |||
| &timeout_runtime, | |||
| logs.split_off(0), | |||
| ) | |||
| .await; | |||
| .await | |||
| .and(exporter.as_mut().force_flush()); | |||
There was a problem hiding this comment.
Do we need this? export_with_timeout already calls exporter.export which is what is expected from force_flush.
Fixes #2261
Design discussion issue (if applicable) #
Changes
Added the force_flush interface to LogExporter and call it in the LogProcessor, right after flushing the export queue.
Merge requirement checklist
CHANGELOG.mdfiles updated for non-trivial, user-facing changes