The statsv client maintains an in-memory queue of metrics to send to the server. They will be sent within 2 seconds of being queued. It is possible we might be losing some where the browser is closed within that time.
= Problem
If the queue length is under 50 (an internally set maximum batch size), then the metrics are sent to the server/dequeued two seconds after the last metric was added to the queue (A). If the queue length is over 50, then a batch of metrics are sent to the server/dequeued every two seconds until either the queue is empty or the preconditions for A are met.
However, if the queue has metrics in it and the page unloads, then in principle those metrics aren't sent to the server and are lost.
=== Steps to reproduce
1. Visit https://en.wikipedia.org/wiki/Cult_of_Luna
# Open your browser's JavaScript console
# Type `mw.track( 'counter.test.statsv.foo2', 1 )`
# Wait for 2 seconds
# Observe that an HTTP GET request is sent to the following URL: /beacon/statsv?test.statsv.foo2=1c
# Type `mw.track( 'counter.test.statsv.foo2', 1 )`
# Refresh the page within 2 seconds (e.g. before the request has a chance to send)
# Observe that no HTTP GET request has been sent and the event dropped
=== AC
* When the page unloads, any metrics in the queue should be sent to the server
* When the page loses visibility, any metrics in the queue should be sent to the server
=== Notes
1. @phuedx: The AC around page visibility comes from a conversation with @Krinkle. IIRC, in some mobile browsers, the `unload` event doesn't fire before the JavaScript VM is torn down after a tab is closed. However, we're more confident that the `visibilitychange` event does fire.
= Developer notes
- See T208980#4792762
- The change should live in WikimediaEvents inside stasd.js
- A window.unload event should empty anything that's in the queue so it is dispatched.