936793 - [Dialer] Call log migration error from 1.0 to 1.1: "TypeError: number is null"

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Dialer, defect)

Description

[Julien Wajsberg [:julienw]]

A user on IRC reported a migration issue when manually updating his phone to v1.1.

When he goes in the call log, he sees a modal progress bar (probably trying to migrate  the call log info to newer version) and the progress blocks at 80%.

In the logcat, the error is stated as:

E/GeckoConsole( 2010): [JavaScript Error: "TypeError: number is null" {file: "app://communications.gaiamobile.org/dialer/js/contacts.js" line: 104}]
E/GeckoConsole( 2010): [JavaScript Error: "TypeError: db is null" {file: "app://communications.gaiamobile.org/dialer/gaia_build_defer_index.js" line: 119}]
E/GeckoConsole( 2010): [JavaScript Error: "AbortError" {file: "app://communications.gaiamobile.org/dialer/gaia_build_defer_index.js" line: 114}]

I investigated this a bit and I think this might happen when there was a hidden number in the call log. The user confirmed he had such a hidden number in his call log.

This is extremely serious because this leaves the call log in an unusable state. The good news is that this can be fixed by an update.

Comment 1

[Julien Wajsberg [:julienw]]

> A user on IRC reported a migration issue when manually updating his phone to v1.1.

I'll correct this: the user updates his phone using an official update from Movistar.

Comment 2

[Nicolae Surdu]

I'm the mentioned IRC user and I'm at your disposal for any further questions.

Comment 3

[Etienne Segonzac (:etienne)]

Looking at the call_log/contacts code across the different versions it looks like we always had empty strings for withheld numbers. If this isn't the case on one particular device hopefully we can find the appropriate image and reproduce the bug.

Nicolae which phone are you using?

But given that this is happening during a DB migration I'm also concerned about the |db is null| error.
Cc'ing ferjm for that.

Comment 4

[Julien Wajsberg [:julienw]]

some thoughts about that "db is null" error:

[1] : errorCode is null (error.name is what you should use, MDN was wrong ;) ), and therefore in [2] we don't detect there is an error, and you call `db.transaction` on a null object. Use `event.target.error.name || 'unknown error` instead.

[3] : same thing, we don't know if ex.message exists. Maybe using `ex.message || 'unknown error'` would be better.

[1] https://github.com/mozilla-b2g/gaia/blob/v1-train/apps/communications/dialer/js/call_log_db.js#L102
[2] https://github.com/mozilla-b2g/gaia/blob/v1-train/apps/communications/dialer/js/call_log_db.js#L178
[3] https://github.com/mozilla-b2g/gaia/blob/v1-train/apps/communications/dialer/js/call_log_db.js#L152

Comment 5

[Etienne Segonzac (:etienne)]

Thinking about it, if the call log worked before it means that withheld numbers where empty strings.

And since it breaks during the migration (as opposed to after having received a _new_ withheld number incoming call) it doesn't look like a specific RIL related issue.

So back to indexeddb.

Comment 6

[Jason Smith [:jsmith]]

Putting QA Wanted to see if someone can reproduce this in house.

Comment 7

[Tony Chung [:tchung]]

What we can try and do Monday, is to take a zte Spain 1.0.1 image and hopefully force update to 1.1 using the zte servers.

We can also try our own inhouse 1.0.1 nightly builds and force ota those.  

Both scenarios, we'll generate some call log history first and see if it reproduces after the update.   Am I understanding the steps correctly?

Comment 8

[Tony Chung [:tchung]]

(In reply to Jason Smith [:jsmith] from comment #6)
> Putting QA Wanted to see if someone can reproduce this in house.

Jason, Marcia, can you guys take a look on monday and flash a zte open phone with the zte 1.0.1 production build from their fTP server?   See if qanalysts can assist.

once we have that loaded, try my suggestions in comment 7.

Comment 0 also indicates having a "hidden number".  so will need to add that to the repro steps.

Comment 9

[Julien Wajsberg [:julienw]]

In v1.0.1 it seems we're adding the entry in the "recent" DB without checking if number is null, and therefore this can probably happen easily.

In v1.1 we're checking if it's null, and if it's null we use the empty string instead. We don't check for "undefined" though, which might or might not be a problem.

Comment 10

[[:Cww]]

We're seeing this or something like this quite a bit on input. Seems to affect both ZTE and TCL devices.

LMK if you need more info or want us to start contacting users

Here's a sample of what I've got:

No registra las llamada con el nuevo software -- Doesn't record the call with the new software

El registro de llamadas queda en blanco desde el update del SO.	-- The call log is blank since the OS update .

Descarga la actualixacion del sistema u tengo problemas al buscar el registro de llamadas u cuando se puede usar imtangran u whatsaap	Download the system update or I have problems finding the call log or when you can use imtangran or whatsaap

Entra en círculo vicioso el accesos a llamadas pérdidas, motrando un 0%.. que nunca termina. Perder esta información  es muy grave. Deberían darle prioridad.	Enter the vicious cycle on missed calls, shows 0% .. that never ends. Losing this information is very serious. Should be given priority.

Buenos días amigo tras la actualización a la versión 1.1 del alcatel he notado que en la parte del teléfono al ir a registro de llamada se pone a cargar llega hasta 30% y ahí se queda colgado  y nunca carga esperó su pronta respuesta. Saludos.	Good morning friend after upgrading to version 1.1 of Alcatel 've noticed that on the phone to go to call log is set to load reaches 30 % and hangs there and never waited load your prompt response. Greetings .

Comment 11

[Marcia Knous [:marcia]]

Will look at this - I believe I might still have a 1.0.1 device from Spain that hasn't been updated. Also I assume hidden number = private number?

Comment 12

[Jason Smith [:jsmith]]

Yeah sure. I'll work with Marcia on this on Monday.

Comment 13

[Etienne Segonzac (:etienne)]

(In reply to Julien Wajsberg [:julienw] from comment #9)
> In v1.1 we're checking if it's null, and if it's null we use the empty
> string instead.

I  must have missed a code path during my search but where in the v1.1/current code are we checking if the number is null?

Comment 14

[Julien Wajsberg [:julienw]]

Seems you're right, I may have scanned too quick.

I found [1] here we're doing this, but that's the only place. Not that this seems related because this specific line comes from bug 838114, which was especially dealing with withheld numbers, so it seems withheld numbers might be null after all :)

[1] https://github.com/mozilla-b2g/gaia/blob/v1-train/apps/communications/dialer/js/call_log.js#L748

Comment 15

[Julien Wajsberg [:julienw]]

*Note that this seems related

(otherwise it has an opposite meaning ;) )

Comment 16

[Hubert Lu[:hlu] <[e-mail]>]

I could reproduce this issue on zte open phone with the zte 1.0.1 production build. But I could not find the same log information as bug description. Also upload the logcat file which I have.

For related information is in below,

* Build Info (Both Gecko and Gaia)
  - Build code is from ZTE FTP site, and file name is "B2G_P752C04V1.0.0B10_MOVISTAR.zip"
  - Gaia:     e089ed6095489f3ffd1a891bab70619ab3316c20
  - BuildID   20130621133927
  - Version   18.0
  - Software : OPEN_FFOS_V1.0.0B04_MOVISTAR
  - OS version : 1.0.1.0-prerelease
  - Firmware revision: v1.01.00.01.019.120

* Reproduce Steps
   - Flash device via ZTE tool
   - Enable WiFi connection
   - Make a phone call to DUT from another device (Phone number is viewable)
   - Make another phone call to DUT from other device (Phone number is hidden)
   - Perform check now and tap the update notification
   - Click "Download" to download the updates.
   - Press Install Now to upgrade device while package is downloaded.
   - Launch phone dialer and check call log

* Actual results:
   - The call log launching progress blocks at 10%.

* Expected results:
   - The call log launching progress should be run properly without problem.

Comment 17

[Hubert Lu[:hlu] <[e-mail]>]

Attachment: logcat(call_log).txt

Comment 18

[Fernando Jiménez Moreno [:ferjm]]

I don't have a ZTE open to try, but it seems that it should be reproducible in the Unagi. I might be able to take a look at this at the end of this week. Adding ni? on me so I don't miss it.

Comment 19

[Jason Smith [:jsmith]]

Talked with rel man in person about this - we're going to track this under the koi? umbrella, only because no one is looking at leo bugs anymore. We will discuss today in the drivers meeting if we're going to ask partners to cherry pick this patch onto their 1.1 branch.

Comment 20

[bhavana bajaj [:bajaj]]

Just wanted to clarify the priority on this as, :cww from SUMO/User advocacy just told me that we are seeing a number of reports on this issue. Can someone help look at this asap ?

Comment 21

[bhavana bajaj [:bajaj]]

Can QA help confirm comment #18 by trying a buri or leo, that this is a generic issue and not specific to only ZTE devices ?

Comment 22

[Tony Chung [:tchung]]

(In reply to bhavana bajaj [:bajaj] from comment #21)
> Can QA help confirm comment #18 by trying a buri or leo, that this is a
> generic issue and not specific to only ZTE devices ?

Hold on.  Before QA goes chasing down other devices to try and reproduce, i'd like to see input from Dev if the logcat that was provided in comment 17 is helpful; and does it indicate the issue is related to the device.   I dont want us to spin extra resources without more conclusive evidence.    Keep in mind that different partners use different FOTAs, and we haven none of that.   

Also, leo didnt have 1.0.1.  it deployed with 1.1.

Comment 23

[Fernando Jiménez Moreno [:ferjm]]

(In reply to Tony Chung [:tchung] from comment #22)
> (In reply to bhavana bajaj [:bajaj] from comment #21)
> > Can QA help confirm comment #18 by trying a buri or leo, that this is a
> > generic issue and not specific to only ZTE devices ?
> 
> Hold on.  Before QA goes chasing down other devices to try and reproduce,
> i'd like to see input from Dev if the logcat that was provided in comment 17
> is helpful; and does it indicate the issue is related to the device.   I
> dont want us to spin extra resources without more conclusive evidence.   
> Keep in mind that different partners use different FOTAs, and we haven none
> of that.   
> 
> Also, leo didnt have 1.0.1.  it deployed with 1.1.

Unfortunately, the logcat does not show any information related to this issue.

Comment 24

[Etienne Segonzac (:etienne)]

Looks like this db migration is the only place where we call Contacts.findByNumber on a record without having a specific withheld number code path before.

So probably not device specific, or gecko version specific or ril specific but just the migration being fundamentally broken.

The safest fix is to hardened Contacts.findByNumber I'm preparing a patch.

Comment 25

[Etienne Segonzac (:etienne)]

Attachment: Pointer to gaia PR

Asking QA for feedback since we defintely want to double check this.

(The patch should easily apply on 1.1)

Comment 26

[David Palomino [:dpalomino]]

Hi, 

Is it possible to have this issue also present during OTA updates from 1.1 to 1.2? We should be really sure that this is not happening with 1.2 updates for already commercial 1.1 devices. 

Most of 1.1 are already deployed, so I'm not seeing the way to effectively solve this issue for commercial already-launched devices, but at least we should assure that this bug is solved for updates from 1.1 to 1.2. 

What do you think?

Thanks!
David

Comment 27

[Fernando Jiménez Moreno [:ferjm]]

Comment on attachment 830761 [details] [review]
Pointer to gaia PR

Thanks Etienne!

Comment 28

[Fernando Jiménez Moreno [:ferjm]]

(In reply to David Palomino [:dpv] from comment #26)
> Hi, 
> 
> Is it possible to have this issue also present during OTA updates from 1.1
> to 1.2? We should be really sure that this is not happening with 1.2 updates
> for already commercial 1.1 devices. 
> 
> Most of 1.1 are already deployed, so I'm not seeing the way to effectively
> solve this issue for commercial already-launched devices, but at least we
> should assure that this bug is solved for updates from 1.1 to 1.2. 
> 
> What do you think?
> 
> Thanks!
> David

This would also happen for 1.2 updates without the fix.

What's the current plan regarding hotfixes like this one? Are OTA updates being published with hotfixes (something like a 1.1.1 version)?

Comment 29

[Etienne Segonzac (:etienne)]

Referencing the bug (probably) introducing the upgrade issue. Any branch with this patch should probably get the fix.

Comment 30

[David Palomino [:dpalomino]]

(In reply to Fernando Jiménez Moreno [:ferjm] (use needinfo instead of CC, please) from comment #28)
> This would also happen for 1.2 updates without the fix.

Thanks for the info Fernando!

> 
> What's the current plan regarding hotfixes like this one? Are OTA updates
> being published with hotfixes (something like a 1.1.1 version)?

Currently it's not planned to release 1.1.x versions, as it's difficult for OEMs to assume extra certification costs. However it should be included for sure for 1.2 OTA upgrades. 

I'd suggest to land this specific patch for koi, leo, and hd. 

Thks!
David

Comment 31

[Jason Smith [:jsmith]]

(In reply to David Palomino [:dpv] from comment #30)
> (In reply to Fernando Jiménez Moreno [:ferjm] (use needinfo instead of CC,
> please) from comment #28)
> > This would also happen for 1.2 updates without the fix.
> 
> Thanks for the info Fernando!
> 
> > 
> > What's the current plan regarding hotfixes like this one? Are OTA updates
> > being published with hotfixes (something like a 1.1.1 version)?
> 
> Currently it's not planned to release 1.1.x versions, as it's difficult for
> OEMs to assume extra certification costs. However it should be included for
> sure for 1.2 OTA upgrades. 

This needs to be discussed at a driver's level. From what I can tell, this could hit the criteria for pushing a 1.1.X update, as this hits the chemspill priority of bugs. The difficulty of issuing updates is a factor, but I don't think makes a final decision on not taking this patch on an update. We've got users with a non-functioning call log right now.

Comment 32

[Tony Chung [:tchung]]

(In reply to Etienne Segonzac (:etienne) from comment #25)
> Created attachment 830761 [details] [review]
> Pointer to gaia PR
> 
> Asking QA for feedback since we defintely want to double check this.
> 
> (The patch should easily apply on 1.1)

Thanks Etienne.  i'll work with Hubert today to see if we can pull this patch and run another DM test.

Comment 33

[Hubert Lu[:hlu] <[e-mail]>]

The call log launching progress is still blocked even we pull the patch in the device. We manually perform the process of data migration due to we meet some problems in OTA package built/update process. Please see below for details.

* Build Info (Both Gecko and Gaia)
  - Build code is from ZTE FTP site, and file name is "B2G_P752C04V1.0.0B10_MOVISTAR.zip"
  - Gaia:     e089ed6095489f3ffd1a891bab70619ab3316c20
  - BuildID   20130621133927
  - Version   18.0
  - Software : OPEN_FFOS_V1.0.0B04_MOVISTAR
  - OS version : 1.0.1.0-prerelease
  - Firmware revision: v1.01.00.01.019.120

* Reproduce Steps
   - Flash ZTE production build with root-boot.img.
   - Create call logs (1 unknown number and 2 normal number)
   - Backup DB (/data/local/indexedDB/xxx.....communication.gaiamobile.org)
   - Flash gaia image with patch file, then stop b2g
   - Restore DB
   - Restart b2g, then launch call log page to check status.

* Actual results:
   - The call log launching progress is still blocked at 40%.

Comment 34

[Askeing Yen[:askeing][:fyen]]

Attachment: inari communications.gaiamobile.org.zip

(In reply to hlu from comment #33)
> * Reproduce Steps
>    - Flash ZTE production build with root-boot.img.
>    - Create call logs (1 unknown number and 2 normal number)
>    - Backup DB (/data/local/indexedDB/xxx.....communication.gaiamobile.org)
>    - Flash gaia image with patch file, then stop b2g
>    - Restore DB
>    - Restart b2g, then launch call log page to check status.
> 
> * Actual results:
>    - The call log launching progress is still blocked at 40%.
Here is the DB which contains 3 call logs.

$ sqlite3 2584670174dsitanleecreR.sqlite ".table"
database            index_data          object_store        unique_index_data 
file                object_data         object_store_index
$ sqlite3 2584670174dsitanleecreR.sqlite "select * from index_data"
1|1398972224|%GX1
1|1398972237|%Gn�|3
$ sqlite3 2584670174dsitanleecreR.sqlite "select * from object_data"
1|1|%GX|�|
2|1|%Gf!�||�|
3|1|%Gn�||�|

Comment 35

[Askeing Yen[:askeing][:fyen]]

Attachment: buri communications.gaiamobile.org.zip

Also failed on Buri v1.0.1 to v1.1.0.

### ENV:
Device: Buri
v1.0.1 Base Img: partner v1.0 20130912.cfg
v1.1.0 Base Img: US_20131104_root.cfg
Gaia with patch: ffe1f0d22fa747fd0176b6844746fd37ca835948 (TWCI /job/B2G.master.hamachi/85/)
    $ cd gaia && git log -n 2 --oneline
    ffe1f0d Bug 936793 - HOTFIXing a call log idb migration by hardening the Contacts.findByNumber method.
    cdcb998 Bug 912885 - more tests for bug 912885 r=kaze (cherry picked from commit d4c347b4a4093c86b3b84df2f0af47e4cb19736c)

### STR:
1. flash v1.0.1 Base Imgage. flash boot partition with root access.
2. create call logs (one number, one unknow number).
3. backup DB.
4. flash v1.1.0 Base Imgage.
5. flash v1.1.0 gaia which with patch.
6. restore DB.
7. restart, check call logs.

### Actual result:
The call log upgrade progress is blocked at 20%.

### Note:
$ sqlite3 2584670174dsitanleecreR.sqlite ".table"
database            index_data          object_store        unique_index_data 
file                object_data         object_store_index
$ sqlite3 2584670174dsitanleecreR.sqlite "select * from index_data"
1|1:89836216|��=�@|2
$ sqlite3 2584670174dsitanleecreR.sqlite "select * from object_data"
1|1|��96|�|
2|1|��=�@||�|

Comment 36

[Tony Chung [:tchung]]

Thanks Hubert and Askeing for running these tests!

Julien, this is still reproducing with the gaia patched build.   Can you take a look?   Is there any other testing that can be done here to assist?

Comment 37

[Etienne Segonzac (:etienne)]

(In reply to Tony Chung [:tchung] from comment #36)
> Thanks Hubert and Askeing for running these tests!
> 
> Julien, this is still reproducing with the gaia patched build.   Can you
> take a look?   Is there any other testing that can be done here to assist?

The logcat of the issue reproducing with the patch would be helpful.

Comment 38

[Julien Wajsberg [:julienw]]

Is attachment 832079 [details] a v1.0.1 database?

The most helpful thing would be to have such a database, so that the developers can test on their own phone.

More generally, a unit test creating such an indexeddb and running the upgrade steps, and/or an integration test using a v1.0.1 database and doing the same, could be useful in the future.

Clearing my needinfo flag as Étienne works on this.

Comment 39

[Etienne Segonzac (:etienne)]

I'm able to reproduce the bug on my dev phone by adb pushing the attached files.
So, thanks Askeing!

And I'm working on a updated fix.

Comment 40

[Etienne Segonzac (:etienne)]

Comment on attachment 830761 [details] [review]
Pointer to gaia PR

Updated path.

Since I was able to reproduce the issue I'm pretty confident about this fix but I'd appreciate having a QA engineer verify this.

Comment 41

[Jason Smith [:jsmith]]

Blocking on this for 1.2 to ensure this gets on 1.2 branches at least. There's discussion offline to see if we can get this into 1.1 or not on an update.

Comment 42

[Askeing Yen[:askeing][:fyen]]

(In reply to Etienne Segonzac (:etienne) from comment #40)
> Comment on attachment 830761 [details] [review]
> Pointer to gaia PR
> 
> Updated path.
> 
> Since I was able to reproduce the issue I'm pretty confident about this fix
> but I'd appreciate having a QA engineer verify this.
It works fine now, thank you Etienne :-)

### ENV:
Device: Ikura
Base Img: the same as Comment 33
Gaia with patch: d3c72ea746f9394e2584b368781565a374513837 (TWCI /job/B2G.v1train.inari/91/)
    $ cd gaia && git log -n 2 --oneline
    d3c72ea Bug 936793 - HOTFIXing a call log idb migration by hardening the Contacts.findByNumber method.
    4fa6e63 Merge pull request #13710 from fabi1cazenave/backout-commit-dadecdea

### STR:
0. download the DB from Comment 34 (1 unknown number and 2 normal number).
1. flash Partner Build. flash boot partition with root access.
2. flash v1.1.0 gaia with patch.
3. stop b2g, then restore DB.
4. restart, check call logs.

### Expected result:
The call log launching progress should run properly.
There are 3 call logs (1 withhold number and 2 normal number).

### Actual result:
As expected.

Comment 43

[Fernando Jiménez Moreno [:ferjm]]

Comment on attachment 830761 [details] [review]
Pointer to gaia PR

Thanks Etienne!

Comment 44

[Etienne Segonzac (:etienne)]

Comment on attachment 830761 [details] [review]
Pointer to gaia PR

Clearing the f? since we got confirmation that the patch works.

Comment 45

[Etienne Segonzac (:etienne)]

https://github.com/mozilla-b2g/gaia/commit/300a4e05fef44a4f47a3f573446de6311b317434

Landed on master, let me know if I can help in any way with the mess that uplifiting everywhere might be.

Comment 46

[Tony Chung [:tchung]]

(In reply to Etienne Segonzac (:etienne) from comment #45)
> https://github.com/mozilla-b2g/gaia/commit/
> 300a4e05fef44a4f47a3f573446de6311b317434
> 
> Landed on master, let me know if I can help in any way with the mess that
> uplifiting everywhere might be.

Etienne, given this has been koi+'d, can you also uplift the patches to 1.2?   

Hubert/Askeing, once it's been successfully uplifted, can you retest and verify the fix on 1.2?    

Thanks everyone!

Comment 47

[Julien Wajsberg [:julienw]]

Tony, I think this should be leo+ and land on 1.1 asap too. Geeksphone still do builds out of the latest v1-train, and our partners could do a 1.1.1 release out of it too.

Comment 48

[Nicolae Surdu]

Just a small update: now, when switching to call log, it's always empty and the migration doesn't even start. The relevant part from logcat looks like it's this:

E/GeckoConsole( 8548): [JavaScript Error: "NotFoundError: The operation failed because the requested database object could not be found. For example, an object store did not exist but was being opened." {file: "app://communications.gaiamobile.org/dialer/gaia_build_defer_index.js" line: 119}]\

If you need the full log, just let me know.

Comment 49

[Tony Chung [:tchung]]

(In reply to Julien Wajsberg [:julienw] from comment #47)
> Tony, I think this should be leo+ and land on 1.1 asap too. Geeksphone still
> do builds out of the latest v1-train, and our partners could do a 1.1.1
> release out of it too.

While I agree with you, it's the partners call to take this patch or not in 1.1.1.  If you want to nom this for Leo, please drop an email to b2g-internal to discuss.  i am not aware of anyone in triage looking at leo? bugs right now.  

For now, you're cleared to land on status-b2g-v1.2.  thanks!

Comment 50

[Jack Liu]

Dears, nominate leo? because it impacts v1.1 end users, it has been reproduced on buri devices.

Thanks!

Comment 51

[Jason Smith [:jsmith]]

(In reply to Jack Liu from comment #49)
> Dears, nominate leo? because it impacts v1.1 end users, it has been
> reproduced on buri devices.
> 
> Thanks!

We know that. We discussed this offline - we marked koi+ to get this landed on 1.2 branches or later to ensure it's picked up in 1.2. However, nobody is triaging or tracking leo bugs anymore, so we don't want to set that flag for tracking. Instead, our current plan was that partners who want to take this patch on a FOTA update should cherry pick the patch onto the 1.1 branch directly.

Resetting the koi+ flag so we don't track of this.

Comment 52

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #50)
> (In reply to Jack Liu from comment #49)
> > Dears, nominate leo? because it impacts v1.1 end users, it has been
> > reproduced on buri devices.
> > 
> > Thanks!
> 
> We know that. We discussed this offline - we marked koi+ to get this landed
> on 1.2 branches or later to ensure it's picked up in 1.2. However, nobody is
> triaging or tracking leo bugs anymore, so we don't want to set that flag for
> tracking. Instead, our current plan was that partners who want to take this
> patch on a FOTA update should cherry pick the patch onto the 1.1 branch
> directly.
> 
> Resetting the koi+ flag so we don't track of this.

so we don't lose track of this*

Comment 53

[Jason Smith [:jsmith]]

Discussed in drivers & email thread - marking leo+ to allow a landing for 1.1.

Comment 54

[Askeing Yen[:askeing][:fyen]]

Test on v1.2 by cherry-pick 65c7f7ab83156fe8d9259d359a23e6e58c3e45a1

### ENV:
Buri
v1.2 Gaia with patch: f0bc4504dc4a0ae8bb308bac44622aef1cbc645d (TWCI /B2G.master.hamachi/93/)
f0bc450 Bug 936793 - HOTFIXing a call log idb migration by hardening the Contacts.findByNumber method.
9439907 Merge pull request #13811 from mcav/fix-gmail-email-polling-v1.2

### STR:
1. flash v1.0.1 Base Imgage. flash boot partition with root access.
2. create call logs (1 number, 1 unknow number).
3. backup DB (/data/local/indexedDB/xxx...communication.gaiamobile.org/*.sqlite*).
4. flash v1.2.0 Base Imgage.
5. flash v1.2.0 gaia which with patch.
6. restore DB (/data/local/storage/persistent/xxx...communications.gaiamobile.org/idb/).
7. restart, check call logs.

### Expected result:
The call log launching progress should run properly.
There are 2 call logs (1 number, 1 unknow number)..

### Actual result:
As expected.

Comment 55

[Julien Wajsberg [:julienw]]

John, could you please assist with the uplift?

Comment 56

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted 300a4e05fef44a4f47a3f573446de6311b317434 to:
v1-train: b7610870ec71495685557744bfbcbce357032251
v1.2: 777bbf2e2917b2aed2f6a710be75e17518ed0806

Comment 57

[Tim Guan-tin Chien [:timdream] (please needinfo)]

v1.1.0hd: b7610870ec71495685557744bfbcbce357032251

Comment 58

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

FYI, I think you guys are aware of this bug and have spoken to the OEMs about this, but just in case, pinging you guys on this fix.

Comment 59

[Wayne Chang [:wchang]]

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #58)
> FYI, I think you guys are aware of this bug and have spoken to the OEMs
> about this, but just in case, pinging you guys on this fix.

Thanks.

From reading the thread I understand the fix should be in the target version, not the base version.

Comment 60

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Wayne, I'm not sure what you mean?  This needs to be fixed in the next production version (base build)  The issue is already out in production.  (see comment 1)

Comment 61

[Wayne Chang [:wchang]]

Thanks got it.

Comment 62

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Thanks for the information Naoki

Comment 63

[Julien Wajsberg [:julienw]]

Did a fixed build been issued to the users ? 1.5 months since this was fixed already.