2005554 - flushQueuedInitialTasks can block the main thread and still miss additional tasks

Status: NEW

(Data Platform and Tools :: Glean: SDK, defect, P1)

Description

[Jan-Erik Rediger [:janerik] (Away 2026-08-24 - 2026-08-28)]

We currently use a dispatcher to delay certain metric/ping methods.
This is to avoid calling into libxul (where the glean-core functions are), as that itself might cause a libxul load. We don't want that load until Gecko itself does it (and Glean is initialized).

However the current implementation is buggy:

1. While asked to queue things (queueInitialTasks=true) we append tasks to a concurrent queue
2. On init we call flushQueuedInitialTasks, which
   • locks the dispatcher
   • copies tasks from the queue and clears it
   • runs each task
   • sets flushQueuedInitialTasks=false
3. Continues with work

Any task that tries to queue during step 2, just after the dispatcher is locked, gets blocked. When it unlocks it adds to the queue. The task stays there and is never executed.
This can lose tasks, while also blocking the calling thread trying to enqueue a task.

Visible in this profile: https://share.firefox.dev/4427Ekt

1. setEnabled is called
2. DelayedTaskQueue.launch is called
3. this causes an art::Monitor::lock() call, which blocks.

Comment 1

[BMO Github Automation]

Attachment: [mozilla/glean] Bug 2005554 - Kotlin: Rewrite Dispatcher to offload metrics to not cause main blocks (#3361)