2015101 - Nimbus Client should gracefully degrade with empty data when all enrollment stores are unavailable

Status: NEW

(Firefox :: Nimbus Desktop Client, defect, P3)

Description

[Jared Lockhart [:jlockhart]]

When the Nimbus enrollment store fails to initialize (e.g., because ProfilesDatastoreService cannot open its SQLite database), the ExperimentStore's ready() promise hangs forever. This caused bug 2014616 — a completely blank newtab page in Firefox 147.0.3 — because AboutNewTab gates on NimbusFeatures.ready().

Bug 2014616 was fixed by ensuring the Profile Groups directory is always created, but the Nimbus SDK itself should be resilient to store initialization failures so that any future storage problem degrades gracefully rather than hanging all consumers.

Current behavior:

In SharedDataMap.init(), _syncToChildren() and _checkIfReady() are inside the try block, after the optional database initialization call. If the database init throws, execution jumps to the catch block, _checkIfReady() is never called, and the ready() promise hangs forever — even when _data was already successfully loaded from the JSON file.

If both stores fail, _data remains null and the promise also hangs forever.

Proposed fix:

Move _syncToChildren() and _checkIfReady() out of the try block in SharedDataMap.init(), and add a fallback so that if all stores fail, _data is set to {} (empty). This way:

1. If JSON loads but DB fails (the bug 2014616 scenario), the store becomes ready with the JSON data — no behavior change for the user.
2. If everything fails, the store becomes ready with empty data — no active enrollments, all NimbusFeatures APIs return manifest defaults and fallback pref values. The worst case becomes "no experiments this session" rather than "blank page forever."

The empty-data path is safe end-to-end: getAll() returns [], getExperimentForFeature() returns undefined, getAllVariables() returns {...prefGetters, ...defaultValues}, and getVariable() falls back to fallback prefs. No errors, no blank pages.

Additionally, ExperimentStore._reportStartupDatabaseConsistency() should be wrapped in a try-catch since it also hits the database and is telemetry-only — it should never break store initialization.

See also: bug 2014616

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:beth, could you have a look please?

For more information, please visit BugBot documentation.