Add telemetry to track potential breakage due to larger DNS grace period
Categories
(Core :: Networking: DNS, enhancement, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox138 | --- | fixed |
People
(Reporter: omansfeld, Assigned: omansfeld)
References
Details
(Whiteboard: [necko-priority-next][necko-triaged])
Attachments
(1 file)
See comment #5 in bug 1937022
Re: Follow up experiment with grace period increased
I think it makes sense to implement telemetry that checks when the longer grace period could lead to breakage.
My thought process is that when the cache renewal that is triggered when an entry is in the grace period produces a result that is different than the cached entry then we have potentially broken something by introducing the grace period and should record that in telemetry so we can see if the experiment has a negative impact (or how big that impact is).
| Assignee | ||
Comment 1•1 year ago
|
||
(Some additional info from :valentin (he/him) from comment #6 on bug 1937022
I'm very much in favor of adding some telemetry for this, though the grace period isn't the only case in which we refresh DNS records.
If you have tab A and B open to the same origin, and tab B gets force-refreshed, that would also update the DNS cache entries available to tab A, which is similar to the grace period refresh, but I'll grant you that the grace period is something we'll probably hit more often.
Regardless, I think this is good telemetry to have.
I'm also quite curious to see how often the refreshed DNS request fails.
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 2•1 year ago
|
||
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Backed out for causing build bustages @ nsHostResolver.cpp
Comment 6•1 year ago
|
||
| bugherder | ||
| Assignee | ||
Updated•1 year ago
|
Description
•