Stop syncing for random failing Places tests, and make sheriffs happier

RESOLVED FIXED in mozilla1.9.3a1

Status

()

Product:
Toolkit
Component:
Places
Type:
defect
Status:
RESOLVED FIXED
Opened:
10 years ago
Updated:
9 years ago

People

(Reporter: mak, Assigned: mak)

Tracking

Version:
Trunk
Target:
mozilla1.9.3a1
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

patch v1.1
6.97 KB, patch
Details | Diff | Splinter Review 
We can disable the Flush component for random failing tests, that way tests will stop failing, but still test code paths. since we know the reason of the failures but we don't have clear ETA on a proper fix (would require moving most of Places to async stuff), this should allow us to have greener trees.

I'm trying to centralize it in head files so it should be easy to update or remove the workaround.
Assignee: nobody → mak77
Status: NEW → ASSIGNED
Posted patch patch v1.0 (obsolete) — — Splinter Review 
This should "fix" about 11 random failures
Attachment #405266 - Flags: review?(sdwilsh)
Of course, these failing tests are real bugs in our code.  I'm not sure we want to make the tests not test real world behavior.
once we have identified the cause and we know the fix, and we know we can't fix that in less than 1 year, why should we continue to blame the trees with useless oranges?
this fix is not hiding anything, it's just stopping notifying about a pretty well known bug, for which bugs are and will remain open.
And i think a good part of the bug involves virtual machines, i'm saying that because i see different number of hits for failures in real world again virtual machines,  vms are probably handling threads differently.

Plus the way this is implemented allow us to disable the full thing with really minor changes to try any patch we think can fix the underlying issue.
the "alternative" as you know, is to disable tests, and that's not better in any way.
Comment on attachment 405266 [details] [diff] [review]
patch v1.0

Include the bug number where we are tracking the underlying issue in the comment please.

r=sdwilsh
Attachment #405266 - Flags: review?(sdwilsh) → review+
ugh i was sure to have done that :\
Posted patch patch v1.1 — — Splinter Review
Attachment #405266 - Attachment is obsolete: true
http://hg.mozilla.org/mozilla-central/rev/239c5018acec

let's see how this behaves.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
one name was wrong and the test was still reporting failures, fixed.
http://hg.mozilla.org/mozilla-central/rev/0ccc8bcf05f0

looks like random oranges for these tests have stopped. still evaluating and waiting reports though.
Blocks: 555983
Blocks: 527134
Blocks: 555014
Blocks: 527633
Blocks: 559279
Blocks: 524524
You need to log in before you can comment on or make changes to this bug.