Closed Bug 1039961 Opened 10 years ago Closed 10 years ago

[B2G][OTA] The migration process is performed twice if the user enters in the tutorial

Categories

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

Product:
Firefox OS Graveyard
Component:
Gaia::Homescreen
Platform:
All
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(b2g-v2.0 fixed, b2g-v2.1 fixed)

Status:
RESOLVED FIXED
Milestone:
2.0 S6 (18july)
Tracking Flags:
Tracking Status
b2g-v2.0 --- fixed
b2g-v2.1 --- fixed

People

(Reporter: crdlc, Assigned: crdlc)

References

Details

(Whiteboard: [systemsfe])

Attachments

(1 file)

Github pull request
(deleted), text/html
kgrandon
: review+
macajc
: review+
bajaj
: approval-gaia-v2.0+
Details
There is nor dataloss neither issues but we are consuming a lot of resources performing this task twice when it is not needed
Assignee: nobody → crdlc
Blocks: 1015336
Status: NEW → ASSIGNED
blocking-b2g: --- → 2.0?
Whiteboard: [systemsfe]
Attached file Github pull request (deleted) —
The migrator should be clever and to know when the migration was performed or not independent on number of calls
Attachment #8457831 - Flags: review?(kgrandon)
Attachment #8457831 - Flags: review?(carmen.jimenezcabezas)
Comment on attachment 8457831 [details] Github pull request Seems a bit sketchy to depend on this specific value, but I can't think of a better solution, so WFM.
Attachment #8457831 - Flags: review?(kgrandon) → review+
In the end the task is to migrate collections/bookmarks to datastores + save the old-layout. If we have the layout stored, we have been migrated. Datastores without revisiionId does not mean that the migration was not performed because the layout could not have nor collections neither bookmarks. So the only way to know if the migration was performed or not is this. So I don't understand "a bit sketchy" :) (In reply to Kevin Grandon :kgrandon from comment #2) > Comment on attachment 8457831 [details] > Github pull request > > Seems a bit sketchy to depend on this specific value, but I can't think of a > better solution, so WFM.
As discussed online, the user impact is low on that bug. The memory is freed after the tutorial. I don't think we should block on that. This a nice to have though. Do not hesitate to ask for approval after the fix is landed.
blocking-b2g: 2.0? → ---
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking-]
Comment on attachment 8457831 [details] Github pull request This looks good to me, thanks!
Attachment #8457831 - Flags: review?(carmen.jimenezcabezas) → review+
Merged in master: https://github.com/crdlc/gaia/commit/a05ff3a6ac98b5bc584b2ecce9f97da2fcb4749c
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
status-b2g-v2.0: --- → affected
status-b2g-v2.1: --- → fixed
Resolution: --- → FIXED
Comment on attachment 8457831 [details] Github pull request This task is huge because it works with indexedDB and two datastores. If we perform this task twice we will have a memory impact opening the tutorial and also we are consuming more battery when it is not needed. The patch only checks if the migration was done previously and adds an early return. [Approval Request Comment] [Bug caused by] (feature/regressing bug #): no regression [User impact] if declined: no [Testing completed]: yes [Risk to taking this patch] (and alternatives if risky): close to null [String changes made]: no
Attachment #8457831 - Flags: approval-gaia-v2.0?(bbajaj)
Target Milestone: --- → 2.0 S6 (18july)
Attachment #8457831 - Flags: approval-gaia-v2.0?(bbajaj) → approval-gaia-v2.0+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: