dca9b87190
In 3.0, the packet loss metric used to trigger connection status alerts was changed to the one generated by the `startMonitoringNetwork` method used by the connection status modal. Since packet loss thresholds were not adjusted (0.5, 0.1, 0.2), a single lost packet causes the status alert to be permanently stuck on "critical". This is explained by how different those metrics are: - **Before (2.7):** A 5-probe wide calculation of inbound packet loss fraction based on `packetsLost` and `packetsReceived` metrics. - **Now (3.0):** An absolute counter of inbound lost packets. This commit restores the previous packet loss metric used to trigger connection status alerts, reverting to the original collection method via `/utils/stats.js`. This resolves the issue, but further work is needed in subsequent PRs: - Unify the collection done in `/utils/stats.js` with the `startMonitoringNetwork` method. - Incorporate the remote-inbound `fractionsLost` metric to account for packet loss on both legs of the network (in/out). - Update the packet loss metric displayed in the connection status modal to show a more meaningful value (e.g., packet loss percentage over a specific probe interval). An absolute counter of lost packets isn't useful for end users. - Update the alert log to use the fraction or percentage above |
||
|---|---|---|
| .. | ||
| button | ||
| icon | ||
| modal | ||
| status-helper | ||
| component.jsx | ||
| mutations.jsx | ||
| queries.jsx | ||
| service.js | ||