Open ramosbugs opened 3 years ago
btw I just open sourced an OpenTelemetry crate built on top of this crate! https://github.com/ramosbugs/opentelemetry-honeycomb-rs
Thank you for opening this @ramosbugs. Will take a look this weekend time permitting.
@nlopes: gentle ping -- any thoughts on the approach above?
Hi @ramosbugs, apologies for the delay, haven't had the chance to look into this. The approach looks good. If you'd like to put in a PR before I get to this, please feel free.
The current client
flush
interface causes an asynchronous flush: https://github.com/nlopes/libhoney-rust/blob/2f7cdc8b9035e2c1c9605c3476640e7f70400471/src/client.rs#L122-L133That function returns once the stop event has been queued and the new worker has been spawned. It would be useful to have this interface (or another) return a future that callers can wait on in order to determine when the original queue has been emptied.
An example use case is for a serverless (AWS Lambda) function, where we need to flush the events to Honeycomb before the Lambda runtime suspends the execution environment until the next function invocation.
A straightforward solution would be for
stop
to create aoneshot
channel and pass the sender into thestop_event
, and return a future that waits on the receiver. The stop event handler can then send to the channel when it's done flushing. I'd be happy to contribute a PR to do this (I need it pretty badly for a project) if that approach seems reasonable or if there's another approach you'd prefer!