Send batched export items in when visibilityState changes to hidden

[bradfrosty]

• This only affects the JavaScript OpenTelemetry library
• This may affect other libraries, but I would like to get opinions here first

I would like to start a discussion about sending completed, batched export items when document.visibilityState becomes hidden. The visibilitychange event will be fired when the contents of the tab become hidden, which happens when the tab changes, closes, or the page unloads.

The motivation behind this is to gather potentially useful information near the end of the page lifecycle. While there will likely not be many spans/export items available during this time, I am curious to know more what happens near or during the unload of the page.

This should only impact browser consumers utilizing any of the batch processors with the collector exporter. It also should export data in this scenario if navigator.sendBeacon() is supported to prevent a delay of the page unload. If it's not supported, just use the existing behavior.

Due to the new recommendations on MDN and this Volument post on sendBeacon, I think visibilitychange should be used instead of sending in beforeunload as is traditionally recommended with navigator.sendBeacon().

If this were to be implemented, where would it go? Is this more of the responsibility of batch processors? Or is this something that belongs in CollectorExportBrowserBase.ts?

[vmarchaud]

I think this should be handled by each exporter so if you need that in the collector exporter, i believe it should be added there. Potentially adding a buffer that waits for the event to send them. I also believe this should be optional, some might want to send telemetry data asap.

EDIT: Are you interested to make a PR for this ?

[bradfrosty]

I also believe this should be optional, some might want to send telemetry data asap.

Agreed that it should be optional. So this could be a browser specific option extending from CollectorExporterConfigBase.

Potentially adding a buffer that waits for the event to send them.

How would this interop with the BatchSpanProcessor? To me it feels like this is an additional flushing condition for span/metric processors. If using the SimpleSpanProcessor, my understanding is that spans won't be lost near the end of the page lifecycle. But with the BatchSpanProcessor, they won't be flushed until the bufferTimeout or bufferSize is reached.

That's really the core of the problem -- the exporter is currently listening to unload to shutdown, but the BatchSpanProcessor doesn't get an opportunity flush. This makes me think it might be the responsibility of the batch processors, since it is agnostic to the exporter being used.

Are you interested to make a PR for this ?

I would be interested in making a PR for this. I can make an implementation in my application to test it out, and then integrate directly into the library.

As for option names, what do you think? Something along the lines of flushOnVisibilityHidden?

[kkruk-sumo]

@bradfrosty I described my concerns about the unload event handler in issue #2205 .

Actually I can't see a way to implement such automatic flushing in the collector exporter, because spans waits in BatchSpanProcessor and then are processed by some exporter.

Did you succeed with some PR about it? I was thinking about providing browser implementation for the BatchSpanProcessor class with force flushing when the visibilityState becomes hidden.

Also it needs to go together with the exporter implementation, because it will only work when sendBeacon will be used. Currently collector-exporter uses sendBeacon when there are no headers provided, so I guess, that could be described somewhere in the documentation.

[kkruk-sumo]

@bradfrosty I had some time so I prepared a PR for that. You can review it at #2243.

[dyladan]

I think BSP is the correct place to implement this. Exporters don't implement batching because it's offloaded on the span processor. If a user really can't wait for their telemetry data they will likely either use SSP, use BSP with this option disabled, or use BSP and manually flush when their particular situation demands.

[bradfrosty]

Hey @kkruk-sumo I've been a bit busy, so I haven't been able to work on a PR. We've been maintaining manual flush logic for this use case in our OTel configuration, which is working for us now. Thanks for looking into this!