1677150 - Should RLB testing API block on the dispatcher?

Status: RESOLVED FIXED

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

Description

[Alessio Placitelli [:Dexter]]

The current RLB testing APIs block on the dispatcher being outside of test mode. This makes the behaviour slightly different than the other bindings. Consider this test case:

1. create a metric;
2. check that it contains nothing (blocks);
3. init glean.

In Kotlin, the above test is possible:

• the dispatcher is in test mode, so executes things on the main thread;
• (2) will simply return that no value is stored.

Comment 1

[Chris H-C :chutten]

I'm open to design changes here. FOG's test story is three boxes, each half-full of sharp corners, at the moment.

Comment 2

[Alessio Placitelli [:Dexter]]

(In reply to Chris H-C :chutten from comment #1)

I'm open to design changes here. FOG's test story is three boxes, each half-full of sharp corners, at the moment.

Sure! But note that this is really an SDK-decision more than a FOG-decision ;-)

Comment 3

[Jan-Erik Rediger [:janerik] (Away 2026-04-02 - 2026-04-10)]

Note: on e.g. Swift the task still runs off-the-main thread, but the main thread blocks while it waits for the task to finish. The observable behavior is the same, but it might matter where stuff runs.

The current RLB testing APIs block on the dispatcher being outside of test mode.

I don't fully understand this phrasing, so here's my try at summarizing the current behavior:

RLB test methods block on the queue emptying (= finishing all potential recording tasks) to ensure it sees those recorded values in the database.

This is conceptually similar to the other bindings, which ensure serliazation barriers on each task, instead of only on the test methods. That in turn guarantees the above test won't block.

However this slight modification is also at least "surprising":

1. create a metric
2. record value a to the metric
3. check what it contains -> nothing
4. init glean.
5. check what it contains -> a

(I think that's what it does, right? The dispatcher is not unblocked until init)

I actually did implement a "test mode -> serialize" mode initially for the dispatcher in FOG, we took it out to simplify the implementation, as we didn't require it back then.

So the question becomes: what are we trying to solve? Consistency across bindings? Behavior? Avoiding blocking code?
The testing strategy for individual users of the RLB is not great anyway (they need to ensure that Glean is initialized for anything to be happening).
Testing in Firefox is better, as FOG takes care of initialization (still some things to figure out though for external users)

In the short term we could put a check of was_initialize_called into block_on_queue and at least panic if it wasn't, thus giving users (really: us) a better chance to avoid that test pattern than blocking would give us (blocking is time consuming and harder to detect).

Comment 4

[Jan-Erik Rediger [:janerik] (Away 2026-04-02 - 2026-04-10)]

Reasoning in today's SDK meeting was to go for the panicky solution.

Comment 5

[GitHub Bugzilla PR Linker]

Attachment: Link to GitHub pull-request: https://github.com/mozilla/glean/pull/1392