https://hackbot.moz.tools/runs/b6157276-5da1-4e58-bbff-13518982a546
Here is the action that failed with http 400 error:
{
"type": "bugzilla.create_bug",
"params": {
"product": "Toolkit",
"component": "Application Update",
"summary": "update.status_error_code_* metrics have range_max: 100, collapsing updater status codes >= 100 into the overflow bucket",
"version": "unspecified",
"description": "Follow-up from review of [D321460](https://phabricator.services.mozilla.com/D321460) (bug 2066420), requested by :yjuglaret.\n\n### Problem\n\nThe six status-error-code metrics in `toolkit/mozapps/update/metrics.yaml` are declared as:\n\n```yaml\n type: custom_distribution\n range_min: 0\n range_max: 100\n bucket_count: 101\n histogram_type: linear\n```\n\n- `update.status_error_code_complete_startup`\n- `update.status_error_code_partial_startup`\n- `update.status_error_code_unknown_startup`\n- `update.status_error_code_complete_stage`\n- `update.status_error_code_partial_stage`\n- `update.status_error_code_unknown_stage`\n\nWith a 0..100 linear distribution of 101 buckets, the top bucket is the `100` overflow bucket, so every sample >= 100 is collapsed into it. `AUSTLMY.pingStatusErrorCode()` (`UpdateTelemetry.sys.mjs`) passes the code to `accumulateSingleSample()` with no clamping or remapping, so this happens silently.\n\nUpdater status codes have since grown past that limit (`toolkit/mozapps/update/common/updatererrors.h`):\n\n| Code | Name |\n| --- | --- |\n| 100 | `FALLBACKKEY_UNKNOWN_ERROR` |\n| 101 | `FALLBACKKEY_REGPATH_ERROR` |\n| 102 | `FALLBACKKEY_NOKEY_ERROR` |\n| 103 | `FALLBACKKEY_SERVICE_NO_STOP_ERROR` |\n| 104 | `FALLBACKKEY_LAUNCH_ERROR` |\n| 105 | `SILENT_UPDATE_NEEDED_ELEVATION_ERROR` |\n| 106 | `BACKGROUND_TASK_SHARING_VIOLATION` |\n\n105 and 106 are genuinely written to `update.status` by `updater.cpp` (`WriteStatusFile(SILENT_UPDATE_NEEDED_ELEVATION_ERROR)`, `WriteStatusFile(BACKGROUND_TASK_SHARING_VIOLATION)`), so they do reach `pingStatusErrorCode()` and are indistinguishable from each other in the data.\n\n### Notes\n\n- Bug 1940967 (FIXED) removed the glean_parser/Glean 100-bucket cap and explicitly cited `UPDATE_STATUS_ERROR_CODE_*` as a motivating case, so a wider range is no longer blocked by the SDK. It did not change any `update.*` metric definition.\n- Since these metrics were mechanically generated from the Legacy Telemetry enumerated histograms during the bug 1963871 migration, widening the range is a metric-definition change and likely wants new metric names plus a data review rather than an in-place edit of a `expires: never` probe.\n- Not affected: `update.state_code_*` use `range_max: 20` and the highest state code is 14; `update.download_code_*` use 50; `update.bits_result_*` use 99/100.\n- Bug 2066420 does not fix this - if anything it makes the overflow observable, since before it no updater error code reached the `*_startup` probes at all.\n\n### Suggested fix\n\nIntroduce new `custom_distribution` metrics with a range that covers the current code space with headroom (and keep the reserved JS-side ranges in mind: 80-99 for `UpdateService.sys.mjs`, 110-111 reserved), then switch `pingStatusErrorCode()` over to them.",
"is_markdown": true,
"type": "defect",
"see_also": [
"https://bugzilla.mozilla.org/show_bug.cgi?id=2066420",
"https://phabricator.services.mozilla.com/D321460"
],
"depends_on": [
1940967
]
},
"reasoning": "yjuglaret asked in inline comment 1722920 on D321460 to file a follow-up about migrating to new Glean metrics, since the current ones have range_max: 100 while updater status codes now exceed that, unless an existing bug already covers the gap. Verified in the tree: all six update.status_error_code_* metrics are range_min 0 / range_max 100 / bucket_count 101 / linear, and updatererrors.h defines codes 100-106 including SILENT_UPDATE_NEEDED_ELEVATION_ERROR (105) and BACKGROUND_TASK_SHARING_VIOLATION (106), both of which updater.cpp actually writes to update.status. An extensive Bugzilla search (summary and longdesc searches for range_max, bucket_count, custom_distribution, glean, metric, telemetry, histogram, status_error_code, and the two error-code names, plus the dependency lists of bug 2061897 and bug 1963871) found no bug covering this; the closest, bug 1940967, only lifted the Glean SDK bucket cap and changed no update.* definition. Filing rather than commenting because the reviewer requested it explicitly and the duplicate check came back clean."
}
https://hackbot.moz.tools/runs/b6157276-5da1-4e58-bbff-13518982a546
Here is the action that failed with http 400 error:
{ "type": "bugzilla.create_bug", "params": { "product": "Toolkit", "component": "Application Update", "summary": "update.status_error_code_* metrics have range_max: 100, collapsing updater status codes >= 100 into the overflow bucket", "version": "unspecified", "description": "Follow-up from review of [D321460](https://phabricator.services.mozilla.com/D321460) (bug 2066420), requested by :yjuglaret.\n\n### Problem\n\nThe six status-error-code metrics in `toolkit/mozapps/update/metrics.yaml` are declared as:\n\n```yaml\n type: custom_distribution\n range_min: 0\n range_max: 100\n bucket_count: 101\n histogram_type: linear\n```\n\n- `update.status_error_code_complete_startup`\n- `update.status_error_code_partial_startup`\n- `update.status_error_code_unknown_startup`\n- `update.status_error_code_complete_stage`\n- `update.status_error_code_partial_stage`\n- `update.status_error_code_unknown_stage`\n\nWith a 0..100 linear distribution of 101 buckets, the top bucket is the `100` overflow bucket, so every sample >= 100 is collapsed into it. `AUSTLMY.pingStatusErrorCode()` (`UpdateTelemetry.sys.mjs`) passes the code to `accumulateSingleSample()` with no clamping or remapping, so this happens silently.\n\nUpdater status codes have since grown past that limit (`toolkit/mozapps/update/common/updatererrors.h`):\n\n| Code | Name |\n| --- | --- |\n| 100 | `FALLBACKKEY_UNKNOWN_ERROR` |\n| 101 | `FALLBACKKEY_REGPATH_ERROR` |\n| 102 | `FALLBACKKEY_NOKEY_ERROR` |\n| 103 | `FALLBACKKEY_SERVICE_NO_STOP_ERROR` |\n| 104 | `FALLBACKKEY_LAUNCH_ERROR` |\n| 105 | `SILENT_UPDATE_NEEDED_ELEVATION_ERROR` |\n| 106 | `BACKGROUND_TASK_SHARING_VIOLATION` |\n\n105 and 106 are genuinely written to `update.status` by `updater.cpp` (`WriteStatusFile(SILENT_UPDATE_NEEDED_ELEVATION_ERROR)`, `WriteStatusFile(BACKGROUND_TASK_SHARING_VIOLATION)`), so they do reach `pingStatusErrorCode()` and are indistinguishable from each other in the data.\n\n### Notes\n\n- Bug 1940967 (FIXED) removed the glean_parser/Glean 100-bucket cap and explicitly cited `UPDATE_STATUS_ERROR_CODE_*` as a motivating case, so a wider range is no longer blocked by the SDK. It did not change any `update.*` metric definition.\n- Since these metrics were mechanically generated from the Legacy Telemetry enumerated histograms during the bug 1963871 migration, widening the range is a metric-definition change and likely wants new metric names plus a data review rather than an in-place edit of a `expires: never` probe.\n- Not affected: `update.state_code_*` use `range_max: 20` and the highest state code is 14; `update.download_code_*` use 50; `update.bits_result_*` use 99/100.\n- Bug 2066420 does not fix this - if anything it makes the overflow observable, since before it no updater error code reached the `*_startup` probes at all.\n\n### Suggested fix\n\nIntroduce new `custom_distribution` metrics with a range that covers the current code space with headroom (and keep the reserved JS-side ranges in mind: 80-99 for `UpdateService.sys.mjs`, 110-111 reserved), then switch `pingStatusErrorCode()` over to them.", "is_markdown": true, "type": "defect", "see_also": [ "https://bugzilla.mozilla.org/show_bug.cgi?id=2066420", "https://phabricator.services.mozilla.com/D321460" ], "depends_on": [ 1940967 ] }, "reasoning": "yjuglaret asked in inline comment 1722920 on D321460 to file a follow-up about migrating to new Glean metrics, since the current ones have range_max: 100 while updater status codes now exceed that, unless an existing bug already covers the gap. Verified in the tree: all six update.status_error_code_* metrics are range_min 0 / range_max 100 / bucket_count 101 / linear, and updatererrors.h defines codes 100-106 including SILENT_UPDATE_NEEDED_ELEVATION_ERROR (105) and BACKGROUND_TASK_SHARING_VIOLATION (106), both of which updater.cpp actually writes to update.status. An extensive Bugzilla search (summary and longdesc searches for range_max, bucket_count, custom_distribution, glean, metric, telemetry, histogram, status_error_code, and the two error-code names, plus the dependency lists of bug 2061897 and bug 1963871) found no bug covering this; the closest, bug 1940967, only lifted the Glean SDK bucket cap and changed no update.* definition. Filing rather than commenting because the reviewer requested it explicitly and the duplicate check came back clean." }