754780 - If Tb 10 and Tb 11 is skipped, Gloda Scheme change is not correctly detected and gloda error is reported to Error Console by Tb 12 or newer, then Global Search doesn't work

Status: RESOLVED FIXED

(MailNews Core :: Database, defect)

Description

[WADA:World Anti-bad-Duping Agency]

This is spin off of bug 752749 comment #8 for gloda error in bug 752749 comment #0.

If a profile was used by Tb 9 or former, and if Tb 10 use and Tb 11 use is skipped, Gloda Scheme change is not correctly detected and gloda error is reported to Error Console by Tb 12 or newer, then Global Search doesn't work.
So, one of next is needed.
(a) Delete global-messages-db.sqlite, restart Tb 12 or newer.
(b) Use the Tb's profile by Tb 10 or Tb 11 once, and use Tb 12 or newer.

(1-1) With Gloda disabled, start Tb 9.0.1, terminate Tb.
Followng message is shown. Schema change is detected.
> gloda.datastore WARN Global database has been purged due to schema change.
(1-2) With Gloda disabled, start Tb 12.0.1 or Tb 15.0a1
Following error occurs. Global Search doesn't work.
> gloda.datastore ERROR Unexpected error when trying to open the database: ReferenceError: aDBFile is not defined
> gloda.everybody ERROR !!! error loading resource:///modules/gloda/fundattr.js
> gloda.everybody ERROR (resource:///modules/gloda/datastore.js:1423) TypeError: this.asyncConnection is null
> gloda.explattr  ERROR Error in init: TypeError: this.asyncConnection is null
> gloda.everybody ERROR (resource:///modules/gloda/datastore.js:1555) TypeError: this.asyncConnection is null
> gloda.everybody ERROR !!! error loading resource:///modules/gloda/noun_mimetype.js
> gloda.everybody ERROR (resource:///modules/gloda/datastore.js:1423) TypeError: this.asyncConnection is null
> gloda.abattrs   ERROR Error in init: TypeError: this.asyncConnection is null
> gloda.everybody ERROR !!! error initializing resource:///modules/gloda/index_ab.js
> gloda.abattrs   ERROR Error in init: TypeError: this.asyncConnection is null


(2-1) With Gloda disabled, start Tb 9.0.1, terminate Tb.
Followng message is shown. Schema change is detected.
> gloda.datastore WARN Global database has been purged due to schema change.
(2-2) With Gloda disabled, start Tb 10.0.1 or Tb 11.0.1
Followng message is shown. Schema change is detected.
> gloda.datastore WARN Global database has been purged due to schema change.
(2-3) With Gloda disabled, start Tb 12.0.1 or Tb 15.0a1
No gloda related error message is shown. Global Search continues to work.

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

Thanks very much for the excellent detective work!

It appears I rushed the last migration logic fix too much; I apparently did not complete refactoring out the nuke migration logic and did not create a unit test for that code path.  I have a fix and am writing the unit test now.

To summarize, the situation is:

- TB 12+ have broken nuke migration logic.
- TB 10,11 have working nuke migration logic.
- The last schema nuke happened with the release of TB 10, so anyone upgrading from TB 9 or earlier will make gloda want to nuke.  So users who are upgrading from Thunderbird 3.1 will lose gloda.  Although they probably weren't using gloda...

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

Attachment: add 2 tests that fail without the fix, pass with it

Unfortunately, the tests need to be their own tests for realism.

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

Attachment: the fix that fixes the tests, and also thunderbird

This fixes things.  No complicated behaviour is required to correct affected Thunderbird profiles.

What happens right now is that at every startup, gloda goes: "oh no, an out of date database, let me smite it!".  Unfortunately, the smiting backfires and gloda dies instead.  But with this fix, gloda will have the power to smite the database and work again.

Comment 5

[Mark Banner (:standard8)]

Comment on attachment 623940 [details] [diff] [review]
the fix that fixes the tests, and also thunderbird

Thanks for the patches. r=me.

Comment 6

[Andrew Sutherland [:asuth] (he/him)]

pushed to comm-central trunk:
https://hg.mozilla.org/comm-central/rev/f2729b390e7b
https://hg.mozilla.org/comm-central/rev/97f864cca479

Leaving branch landings to Standard8 or someone who understands what the tracking flag means.

Comment 7

[Andrew Sutherland [:asuth] (he/him)]

crap, the tree was closed

Comment 8

[Mark Banner (:standard8)]

Comment on attachment 623939 [details] [diff] [review]
add 2 tests that fail without the fix, pass with it

[Triage Comment]
We'll want this for 13 as well. So a=me.

Comment 9

[Mark Banner (:standard8)]

Checked in:

https://hg.mozilla.org/releases/comm-aurora/rev/5038f76b1431
https://hg.mozilla.org/releases/comm-aurora/rev/4831bab6b12d
https://hg.mozilla.org/releases/comm-beta/rev/166d519fc95e
https://hg.mozilla.org/releases/comm-beta/rev/01303a6f3d9b

Comment 10

[Andrew Sutherland [:asuth] (he/him)]

Standard8, can this land on 12 as well, so the fix can ride-along if we release a new build of 12 for security reasons?

Comment 11

[Mark Banner (:standard8)]

(In reply to Andrew Sutherland (:asuth) from comment #10)
> Standard8, can this land on 12 as well, so the fix can ride-along if we
> release a new build of 12 for security reasons?

With a week to go, I'm not sure that is likely. At the moment 12 would need a lot of mozconfigs & things landing on it (for the new automation) if we did a security release, so I'm going for not landing at the moment, and we'll land it if we happen to have one.