View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 5730 | Composr website (compo.sr) | General / Uncategorised | public | 2024-04-24 18:29 | 2024-04-28 23:36 |
| Reporter | PDStig | Assigned To | PDStig | ||
| Priority | normal | Severity | feature | ||
| Status | resolved | Resolution | fixed | ||
| Summary | 5730: Telemetry: use hashes for detecting repeat error reports instead of the error itself | ||||
| Description | When a site submits an error report through telemetry, we want to reduce the number of entries we have on the site's end especially when the same error is reported multiple times. Currently, this is done by checking if the error text already exists in the database. But this has a few problems: * The error often has temporary / unique IDs in them, so the same error may not actually match due to a different unique ID * Same as above but for timestamps or other IDs Instead, add an additional column in the reported errors for storing an MD5 hash. The MD5 hash is generated using the following process: 1) Start with the error message reported 2) Remove everything that looks like a uniqid or md5 hash (replace with "(uniqid)" or "(md5 hash)") 3) Remove everything that looks like it could be a timestamp (for our intents and purposes, we will define this as any epoch integer between January 1, 2017 [the year v10 came out] and the maximum 32-bit integer) (replace with "(timestamp?)") 4) Run a password censor on it 5) Generate the MD5 from the resulting string, but we still store the unmodified error message string in the database | ||||
| Tags | Roadmap: v11 | ||||
| Attach Tags | |||||
| Time estimation (hours) | |||||
| Sponsorship open | |||||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-04-24 18:29 | PDStig | New Issue | |
| 2024-04-24 18:29 | PDStig | Status | Not Assigned => Assigned |
| 2024-04-24 18:29 | PDStig | Assigned To | => user4172 |
| 2024-04-24 18:29 | PDStig | Tag Attached: Roadmap: v11 | |
| 2024-04-28 23:36 | PDStig | Status | Assigned => Resolved |
| 2024-04-28 23:36 | PDStig | Resolution | open => fixed |
