designcourse
designcourse copied to clipboard
leeper
Expose ability to manually flush
Background I'm running the browser SDK installed through npm inside a Chrome extension (React + Next.js)
Problem The extension is meant to be used for a few seconds before closing, meaning all Javascript code execution halts.
This happens before the SDK flushes logs to Datadog almost 100% of the time.
Potential solution Expose a function to flush logs manually. The Node.js client allows this.
Somewhat related to: https://github.com/DataDog/browser-sdk/issues/767 https://github.com/DataDog/browser-sdk/issues/956
~~I've found a workaround by triggering a visibilitychange event similar to your tests but unsure what the downstream implications of this could be.~~
EDIT: The workaround does not work
Also relevant to #432 (service workers are both short-lived and don't have comparable page exit events to observe)
Hello,
For manual flush, we want to be careful and avoid to end up in situations where every event is sent in a dedicated request, impacting both the end user bandwidth and our servers traffic.
An approach that we were considering was to to trigger a flush when calling the stopSession() API (not yet implemented in logs), forcing the sending of the last events with the end of the session.
Would it be helpful for your use cases?
@bcaudan From what I understand, that's functionality equivalent to a manual flush so I believe it would be :)
Does stopSession() have a delay, or is it a synchronous call? I recognize the dangers of exposing an easy way to overload your servers - maybe a middle ground could be a rate limit so end users attempt a custom batching solution that works for them?
Does stopSession() have a delay, or is it a synchronous call?
it is a synchronous call.
maybe a middle ground could be a rate limit so end users attempt a custom batching solution that works for them
Rate limiting a manual flush API would indeed be an interesting tradeoff, we'll keep this approach in mind.
We have a similar use-case for our Office Add-in, where users will generally have completed their interactions and closed the add-in iframe in which our application runs in under 30 seconds.
As a workaround, it seems manually raising a freeze event will force any batched messages to be flushed:
document.dispatchEvent(new Event('freeze'));
The above workaround does work as long as allowUntrustedEvents is set to true in the init configuration.
+1 to exposing this.
would be really nice to have this for local development. Often I want to test if some more complex logger calls appear properly in DD, so I trigger them and then have to sit around waiting for the API call to send them
Hello @zacaj , For local development, I suggest using the browser SDK extension which allow you to see the events collected, among other things.
