All users were logged out of Bugzilla on October 13th, 2018

Prevent session restores during Talos tests

RESOLVED FIXED

Status

()

RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: bnicholson, Assigned: jmaher)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
Looking at https://tbpl.mozilla.org/?tree=Try&rev=2e32d13eeebf, the failed rck test shows this in the log: "11-29 13:16:59.490 D/BRN     ( 2145): RESTORE!!". This is logged at https://hg.mozilla.org/try/rev/606a875cc58c#l1.27, which means we're doing a session restore.

For consistency between tests, we should avoid doing any session restores. According to gbrown, the rck test sets up a warm-up profile, then reuses that profile in the second run, so we should delete sessionstore.js between runs.
(Reporter)

Updated

6 years ago
Duplicate of this bug: 816332
(Assignee)

Comment 2

6 years ago
is there a pref we can set to turn this off?  We probably encounter this on the mochitest robocop tests as well.
(Reporter)

Comment 3

6 years ago
The session restore is started in Java, so I don't know how we would pref it off.

Session restores are triggered by the existence of sessionstore.js, stored inside of the profile. Since we create a new profile for each test. I don't think this happens in most cases. gbrown said the rck tests are an exception because the same profile is used for multiple phases of the test...do other tests do the same thing?
(Assignee)

Comment 4

6 years ago
I was wrong in my previous comment about mochitest doing this.  For the mochitest rc run, we do create a fresh profile each time.  

This would affect all the talos based tests.  Is there a cost to generate sessionrestore.js?  I can make all the remote talos tests delete it after we initialize the browser and before we launch the test.
(Reporter)

Comment 5

6 years ago
> This would affect all the talos based tests.  Is there a cost to generate
> sessionrestore.js?

Nope - the session JSON is normally created from scratch at startup anyway. If anything, it's more costly to have sessionstore.js exist at startup since the previous session needs to be parsed and restored.
(Assignee)

Comment 6

6 years ago
Created attachment 687192 [details] [diff] [review]
remove sessionstore.js before launching talos (1.0)

jhammel: can you review this with an eye to talos
gbrown: can you review it to sanity check I am removing the right file and comment if there are other files to delete  as well.
Assignee: nobody → jmaher
Status: NEW → ASSIGNED
Attachment #687192 - Flags: review?(jhammel)
Attachment #687192 - Flags: review?(gbrown)

Comment 7

6 years ago
Comment on attachment 687192 [details] [diff] [review]
remove sessionstore.js before launching talos (1.0)

Assuming that this doesn't err out if the file isn't there, r+
Attachment #687192 - Flags: review?(jhammel) → review+
(Assignee)

Comment 8

6 years ago
devicemanager does not error out if the file doesn't exist.

waiting on gbrown and I can land ;)
Comment on attachment 687192 [details] [diff] [review]
remove sessionstore.js before launching talos (1.0)

Review of attachment 687192 [details] [diff] [review]:
-----------------------------------------------------------------

AFAIK, that is the only file that is giving us trouble. I think we want to keep other files (disk cache, startup cache, etc) for "historical reasons" if nothing else.
Attachment #687192 - Flags: review?(gbrown) → review+
(Assignee)

Comment 10

6 years ago
we will be uploading a new talos.zip next week, if this is urgent we can deploy a new talos.zip with just this change sooner:
http://hg.mozilla.org/build/talos/rev/308e75e50c8c
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
(Reporter)

Updated

6 years ago
Depends on: 831045
You need to log in before you can comment on or make changes to this bug.