Closed Bug 1501303 Opened 3 years ago Closed 3 years ago

Perma xpcshell in test_TelemetrySend.js is going to permafail when the Gecko version number is bumped to 66 on 2018-12-10

Categories

(Toolkit :: Telemetry, defect, P1)

defect
Points:
2

Tracking

()

VERIFIED FIXED
mozilla65
Tracking Status
firefox-esr60 --- unaffected
firefox63 --- unaffected
firefox64 --- unaffected
firefox65 + verified

People

(Reporter: ebalazs_, Assigned: chutten)

References

Details

Attachments

(2 files)

Flags: needinfo?(ryanvm)
This is due to the expiry of

TELEMETRY_FAILED_SEND_PINGS_SIZE_KB
TELEMETRY_SUCCESSFUL_SEND_PINGS_SIZE_KB
TELEMETRY_SEND_FAILURE_TYPE

in Firefox 66.

I propose we remove TELEMETRY_*_SEND_PINGS_SIZE_KB as they haven't shown a trend between ping send failures and ping size. (And their bucket allocations are suboptimal anyway, with >60% in the first 0-10KB bucket).

I also propose that we make TELEMETRY_SEND_FAILURE_TYPE permanent and extend its collection to the Release channel to keep an eye on -why- pings fail, to serve the broader goal of Telemetry Client Health monitoring.


(leaving empty priority so we can discuss at triage)
Flags: needinfo?(ryanvm)
Assignee: nobody → chutten
Status: NEW → ASSIGNED
Points: --- → 2
Priority: -- → P1
TELEMETRY_FAILED_SEND_PINGS_SIZE_KB and TELEMETRY_SUCCESSFUL_SEND_PINGS_SIZE_KB
are unmonitored and don't show evidence consistent with the original
hypothesis that size correlates with send failures. So let's remove them.

TELEMETRY_SEND_FAILURE_TYPE is a useful measure to track numbers and types of
send failures, in case they change. So let's make that permanent.

MozReview-Commit-ID: GWaKhrzIvph
Attached file data review request
Attachment #9021497 - Flags: review?(francois)
Comment on attachment 9021497 [details]
data review request

Redirecting to :liuche as :francois is on PTO
Attachment #9021497 - Flags: review?(francois) → review?(liuche)
Comment on attachment 9021497 [details]
data review request

data-review+ only

# Data Review Form (to be filled by Data Stewards)

1) Is there or will there be **documentation** that describes the schema for the ultimate data set available publicly, complete and accurate?
Removing some probes, and extending the expiration for an existing probe w/ documentation

2) Is there a control mechanism that allows the user to turn the data collection on and off? (Note, for data collection not needed for security purposes, Mozilla provides such a control mechanism) Provide details as to the control mechanism available.
Yes, Firefox Telemetry preference

3) If the request is for permanent data collection, is there someone who will monitor the data over time?**
Permanent, :chutten will monitor

4) Using the **[category system of data types](https://wiki.mozilla.org/Firefox/Data_Collection)** on the Mozilla wiki, what collection type of data do the requested measurements fall under?  **
Type 1

5) Is the data collection request for default-on or default-off?
default on, for pre-release channels

6) Does the instrumentation include the addition of **any *new* identifiers** (whether anonymous or otherwise; e.g., username, random IDs, etc.  See the appendix for more details)?
No, errors counts by type

7) Is the data collection covered by the existing Firefox privacy notice?
Yes

8) Does there need to be a check-in in the future to determine whether to renew the data? (Yes/No) (If yes, set a todo reminder or file a bug if appropriate)**
Requesting permanent data collection for Telemetry Client Health monitoring
Attachment #9021497 - Flags: review?(liuche) → review+
Pushed by chutten@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4fe52b757719
Adjust Telemetry Send meta-metrics r=Dexter
Thanks for the heads-up, :aryx. I resolved the eslint error before landing.
Flags: needinfo?(chutten)
https://hg.mozilla.org/mozilla-central/rev/4fe52b757719
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
You need to log in before you can comment on or make changes to this bug.