The good news is that remote settings code doesn't depend on temporary storage initialization (storage for the web). The relevant IDB files live in `permanent/chrome/idb/`, 3870112724rsegmnoittet-es.files and 3870112724rsegmnoittet-es.sqlite We have a telemetry for initialization of directories like this [1] The relevant keys for this bug are "Storage" and "UpgradeStorageFrom1_0To2_0" "Storage" is at 99.99% for Nightly which roughly matches Release. The failure at [2] is covered by the "UpgradeStorageFrom1_0To2_0" key and there are currently 194 failures out of 280 tries on Nightly for last month (we track in only once per FF session). We can also provide exact data for Release using custom queries. There are other upgrades with relevant telemetry, for example "UpgradeStorageFrom1_0To2_0", but they all look good. So there's a high probability that fixing the problem at [2] will improve overall initialization success rate and mitigate the problem with search engines. I'm now preparing a custom FF 78 build which can be used to identify precise directory in user's profile which causes the upgrade to fail. We will then ask the reporter to provide full recursive listing of the directory. [1] https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2020-06-28&include_spill=0&keys=UpgradeStorageFrom1_0To2_0!PersistentOrigin!Storage!TemporaryStorage&max_channel_version=nightly%252F79&measure=QM_FIRST_INITIALIZATION_ATTEMPT&min_channel_version=null&processType=*&product=Firefox&sanitize=0&sort_by_value=0&sort_keys=submissions&start_date=2020-06-01&table=1&trim=1&use_submission_date=0 [2] https://searchfox.org/mozilla-release/rev/e9fe0d92b780775234419a0651fef84f6e8311f2/dom/indexedDB/ActorsParent.cpp#17128
Bug 1649393 Comment 13 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
The good news is that remote settings code doesn't depend on temporary storage initialization (storage for the web). The relevant IDB files live in `permanent/chrome/idb/`, 3870112724rsegmnoittet-es.files and 3870112724rsegmnoittet-es.sqlite We have a telemetry for initialization of directories like this [1] The relevant keys for this bug are "Storage" and "UpgradeStorageFrom1_0To2_0" "Storage" is at 99.99% for Nightly which roughly matches Release. The failure at [2] is covered by the "UpgradeStorageFrom1_0To2_0" key and there are currently 194 failures out of 280 tries on Nightly for last month (we track it only once per FF session). We can also provide exact data for Release using custom queries. There are other upgrades with relevant telemetry, for example "UpgradeStorageFrom1_0To2_0", but they all look good. So there's a high probability that fixing the problem at [2] will improve overall initialization success rate and mitigate the problem with search engines. I'm now preparing a custom FF 78 build which can be used to identify precise directory in user's profile which causes the upgrade to fail. We will then ask the reporter to provide full recursive listing of the directory. [1] https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2020-06-28&include_spill=0&keys=UpgradeStorageFrom1_0To2_0!PersistentOrigin!Storage!TemporaryStorage&max_channel_version=nightly%252F79&measure=QM_FIRST_INITIALIZATION_ATTEMPT&min_channel_version=null&processType=*&product=Firefox&sanitize=0&sort_by_value=0&sort_keys=submissions&start_date=2020-06-01&table=1&trim=1&use_submission_date=0 [2] https://searchfox.org/mozilla-release/rev/e9fe0d92b780775234419a0651fef84f6e8311f2/dom/indexedDB/ActorsParent.cpp#17128
The good news is that remote settings code doesn't depend on temporary storage initialization (storage for the web). The relevant IDB files live in `permanent/chrome/idb/`, 3870112724rsegmnoittet-es.files and 3870112724rsegmnoittet-es.sqlite We have a telemetry for initialization of directories like this [1] The relevant keys for this bug are "Storage" and "UpgradeStorageFrom1_0To2_0" "Storage" is at 99.99% for Nightly which roughly matches Release. The failure at [2] is covered by the "UpgradeStorageFrom1_0To2_0" key and there are currently 194 failures out of 280 tries on Nightly for last month (we track it only once per FF session). We can also provide exact data for Release using custom queries. There are other upgrades with relevant telemetry, for example "UpgradeStorageFrom2_0To2_1", but they all look good. So there's a high probability that fixing the problem at [2] will improve overall initialization success rate and mitigate the problem with search engines. I'm now preparing a custom FF 78 build which can be used to identify precise directory in user's profile which causes the upgrade to fail. We will then ask the reporter to provide full recursive listing of the directory. [1] https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2020-06-28&include_spill=0&keys=UpgradeStorageFrom1_0To2_0!PersistentOrigin!Storage!TemporaryStorage&max_channel_version=nightly%252F79&measure=QM_FIRST_INITIALIZATION_ATTEMPT&min_channel_version=null&processType=*&product=Firefox&sanitize=0&sort_by_value=0&sort_keys=submissions&start_date=2020-06-01&table=1&trim=1&use_submission_date=0 [2] https://searchfox.org/mozilla-release/rev/e9fe0d92b780775234419a0651fef84f6e8311f2/dom/indexedDB/ActorsParent.cpp#17128