1840792 - Multiple errors when opening the legacy and new migration window

Status: RESOLVED FIXED

(Firefox :: Migration, defect)

Description

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Attachment: import_errors.gif

Found in

• 116.0a1

Affected versions

• 116.0a1
• 115.0
• 114.0.2

Tested platforms

• Affected platforms: Windows 10x64 (only on one station)
• Unaffected platforms: Ubuntu 22.04, macOS 12

Steps to reproduce

Note that this happens only on one Windows 10x64 machine and not on other machines.

1. Open the legacy or the new migration window and observe the browser console.

Expected result

• No errors are displayed and the migration window is opened almost instantly.

Actual result

• Multiple errors and migration window takes some time to open.

Regression range

• Last good revision: b26c49cd856bc0429a73edd193c90b53c7b810c7
  First bad revision: af91fa9dc0e9a9739cc61639a7ae6ae557ade4f6
  Pushlog:
  https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b26c49cd856bc0429a73edd193c90b53c7b810c7&tochange=af91fa9dc0e9a9739cc61639a7ae6ae557ade4f6
  Possible regressor: bug 1814941

Additional notes

• Attached a screen recording.
• This happens only on one Windows 10 station. I cannot reproduce the issue on other Windows 10, macOS 12 or Ubuntu 22 stations. I don’t know unfortunately what triggered this.

Comment 1

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Attachment: console-export-2023-6-28_10-37-43.txt

Comment 2

[BugBot [:suhaib / :marco]]

:angelvillalobos1995, since you are the author of the regressor, bug 1814941, could you take a look?

For more information, please visit BugBot documentation.

Comment 3

[Pascal Chevrel (relman team) -> :pascalc|PTO until Sept 2]

Mike, could you have a look please? Thanks

Comment 4

[Mike Conley (:mconley) (:⚙️)]

It looks like this can happen on corrupt databases in the source browser. We probably shouldn't retry db connections if we've determined that the database is corrupt, since it's unlikely to have magically repaired itself in the interim.

Comment 5

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 1840792 - Be more resilient and timely when dealing with database corruption during Chrome browser import. r?kpatenio!

This patch does two things:

1. It makes it so that a corrupt database doesn't result in several retries to
   requery the database, as it's extremely unlikely that a corrupt database is
   going to somehow get repaired in the interim.
2. It makes it so that if any Chrome-based browser resource fails to be acquired
   properly, it still allows other resources from the same (and other!) profiles
   to be imported.

Depends on D182733

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ecb13abfa7f0
Be more resilient and timely when dealing with database corruption during Chrome browser import. r=kpatenio

Comment 7

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/ecb13abfa7f0

Comment 8

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1814941

Comment 9

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected.
:mconley, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox116 to wontfix.

For more information, please visit BugBot documentation.

Comment 10

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 9342256 [details]
Bug 1840792 - Be more resilient and timely when dealing with database corruption during Chrome browser import. r?kpatenio!

Beta/Release Uplift Approval Request

• User impact if declined: Users with corrupted databases in Chrome-based browsers will find that the migration window opens slowly and doesn't list any resources for the browsers with the corrupt databases.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: See comment 0. Probably best if atrif tests this, since they were the ones with the "naturally" corrupt profile.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This is a small, well understood change that simply adjusts our exception handling to make our migration code more resilient to database corruption.
• String changes made/needed: None.
• Is Android affected?: No

Comment 11

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Attachment: firefox_migration_errors.gif

Hello! Unfortunately, I am still seeing multiple Error: Error(s) encountered during statement execution: database disk image is malformed errors when opening the migration wizard with Firefox 117.0a1 (2023-07-10) on the same affected station. This happens only for the first time when opened or after Firefox is restarted and the migration wizard is opened again (see attached .gif). Opening the Import Wizard on the same session again will no longer display the errors. However, it seems that the Couldn't get rows from the Chrome history database. error is not displayed.
Should I file another issue for this?

Comment 12

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 9342256 [details]
Bug 1840792 - Be more resilient and timely when dealing with database corruption during Chrome browser import. r?kpatenio!

Hm. Thanks, atrif. Yes, let's file a new bug for this. Looks like there's a difference between a database being corrupt and a database being malformed.

Comment 13

[Mike Conley (:mconley) (:⚙️)]

Actually, speaking with atrif, I think the patch here adjusts things in a way that is strictly better than what we had before. Namely:

1. It still allows the browser with the malformed database to appear in the dropdown list, offering the other uncorrupted resources (and other uncorrupt profiles from the same browser)
2. It is faster to load the migration wizard on subsequent openings.

I'll re-request beta uplift.

Comment 14

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 9342256 [details]
Bug 1840792 - Be more resilient and timely when dealing with database corruption during Chrome browser import. r?kpatenio!

Beta/Release Uplift Approval Request

• User impact if declined: Users with corrupted databases in Chrome-based browsers will find that the migration window opens slowly every time and doesn't list any resources for the browsers with the corrupt databases (or other profiles of the same browser, even if their databases are fine).
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This is a small, well understood change that simply adjusts our exception handling to make our migration code more resilient to database corruption.
• String changes made/needed:
• Is Android affected?: No

Comment 15

[Dianna Smith [:diannaS]]

Comment on attachment 9342256 [details]
Bug 1840792 - Be more resilient and timely when dealing with database corruption during Chrome browser import. r?kpatenio!

Approved for 116.0b4

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/releases/mozilla-beta/rev/4ee1f11f6123
Be more resilient and timely when dealing with database corruption during Chrome browser import. r=kpatenio,a=dsmith

Comment 17

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Confirming that the Error: Error(s) encountered during statement execution: database disk image is malformed errors are still displayed when first opening the Migration window with Firefox 116.0b4 and 117.0a1 (2023-07-12) on the affected Windows 10x64 machine. The errors are no longer displayed after reopening the migration window on the same session until a Firefox restart.
Chrome primary profile and secondary profiles are still displayed in the migration window and data can be successfully imported.
Marking flags accordingly. The remaining issue will be treated in bug 1842613.

Comment 18

[Ryan VanderMeulen [:RyanVM]]

Did we want to get this on to ESR115 also?

Comment 19

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 9342256 [details]
Bug 1840792 - Be more resilient and timely when dealing with database corruption during Chrome browser import. r?kpatenio!

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Can help improve the experience of people migrating to Firefox ESR from another browser.
• User impact if declined: Users that attempt to import corrupted browser data from Chrome-based browsers will find that the wizard takes a while to appear and that no Chrome-based browsers will ultimately appear in the list.
• Fix Landed on Version: 116
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Small, well-understood change that landed in Nightly and uplifted to Beta, and was verified by QA.

Comment 20

[Dianna Smith [:diannaS]]

Comment on attachment 9342256 [details]
Bug 1840792 - Be more resilient and timely when dealing with database corruption during Chrome browser import. r?kpatenio!

Approved for 115.1esr

Comment 21

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/8ddf1677de18

Comment 22

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Hello! Unfortunately, for some reason, I can no longer reproduce this issue even on affected builds on the station that I could initially reproduce it. I tried to delete Chrome profiles but the issue is still not reproducing and I don't have the steps to replicate this, therefore I cannot verify the issue. Removing the qe+ flag.