Closed Bug 1396890 Opened 9 years ago Closed 9 years ago

Weird e10s option showing up on telemetry.m.o

Categories

(Data Platform and Tools :: General, enhancement, P4)

enhancement

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: chutten, Assigned: abhishekbag0092, Mentored)

Details

(Whiteboard: [good first bug][lang=js])

Cloned over from https://github.com/mozilla/telemetry-dashboard/issues/297 Go to https://mzl.la/2mjZiP7 Click on the "any e10s setting" part of the query Expected: 2 options, "e10s" and "no e10s" Actual: there is a third option, a very large negative number == Commentary == fbertsch commented on Mar 8 Okay so this was a tiny amount of data - at most 3 pings. So I'm not sure it's worth worrying about. However, it might make sense to add expected values for our dimensions to prevent this sort of weirdness in the future. E.g. only allow True/False for e10sEnabled, and record counts of other values during aggregation so we can make sure nothing bad has been missed. OTOH aggregates should contain everything our data does, and doing the above could lead to some bad backfill situations (if there ended up being a significant chunk of pings we didn't process because some value changed and didn't match). chutten commented on Mar 8 Instead of limiting options or limiting aggregates, maybe we can focus on limiting value lengths. Certainly that's something we can do on the dashboard side (max-width that popup). Maybe telemetry.js' sanitized() should erase unpopular options as well as unpopular entries... fbertsch commented on Mar 8 This option comes from https://aggregates.telemetry.mozilla.org/filters/?channel=release&version=50. We'd have to push numbers into the get_filter_options, which is actually a separate table in the database with all filter options for a certain channel/version (and no counts)... wouldn't be very easy. max-width sounds like a good thing though :) == Result == * Make it so that extremely-wide options don't make the UI look weird. * Remove options that have very low counts, when "Sanitize" is true.
Can i work on this bug? I would love some assistance as i am very new to this. I am very excited to get started with contributing to open source and be part of the open source community. Thanks..
You certainly may work on this bug! For assistance, here are some good steps: 0) Have a GitHub account 1) Fork the mozilla/telemetry-dashboard repository 2) Enable your fork's Github Pages setting (in the settings) so you can see what effect your code has when it is hosted. 3) Find the code responsible for that very-wide popup. 4) Put a max-width or some other treatment on it so that it doesn't get so ridiculously wide For extra effort, look for the code that decides what options go into that popup and see if there's some way to tell that the very-wide option has very few data points in it. If there's a way to do that, we can hide that option entirely when the "Sanitize Data" option from the "Advanced Options" section is enabled.
Assignee: nobody → abhishekbag0092
Status: NEW → ASSIGNED
Chris, I have forked the code from the repository, i am currently trying to get a hold of things so i might take a day or two to resolve the issue. Thank you for the instructions from your end. If i have any further issues i will certainly contact you on this trail.
I cannot seem to replicate the scenario which is causing the issue. The code which i am running on my local machine does not show the extra option in the e-10s. Any idea why this is happening?
Try using the same set of options as the link in comment 0 - CONTENT_RESPONSE_DURATION for Release 50: YOUR_LOCAL_MACHINE_URL/new-pipeline/evo.html#!aggregates=median&cumulative=0&end_date=2017-03-07&keys=!__none__!__none__&max_channel_version=release%252F51&measure=CONTENT_RESPONSE_DURATION&min_channel_version=release%252F46&os=Windows_NT&processType=*&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2016-09-20&trim=1&use_submission_date=1
I have made a change in the dashboard.css inside the new-pipeline directory and it has resolved the styling issue for e10s setting i have pushed the changes into my forked repository and the changes can be seen at https://ab0092.github.io/telemetry-dashboard. I have a query regarding the pull request operation, should i make a pull request to get the changes reviewed or should i wait for a response in this trail ?
Pull Request works best for code review. If you'd like to link the two areas, you can "attach" the Pull Request to this bug using the "Attach File" button (paste the link in using "paste text as attachment")
The PR[1] has been merged and it's all looking good! [1]: https://github.com/mozilla/telemetry-dashboard/pull/334
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Product: Webtools → Data Platform and Tools
Component: Telemetry Dashboards (TMO) → General
You need to log in before you can comment on or make changes to this bug.