Add metrics to estimate the benefit of proactive refresh [chromium/src : main]

0 views

Skip to first unread message

Daniel Rubery (Gerrit)

unread,

Oct 9, 2025, 2:51:06 PM (3 days ago) Oct 9

to thefrog, Chromium LUCI CQ, Chromium Metrics Reviews, chromium...@chromium.org, asvitkine...@chromium.org, druber...@chromium.org, net-r...@chromium.org

Attention needed from thefrog

New activity on the change

Open in Gerrit

Related details

Attention is currently required from:

thefrog

Submit Requirements:

Code-Coverage
Code-Owners
Code-Review
Review-Enforcement

Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings.

Gerrit

satisfied_requirement

unsatisfied_requirement

open

diffy

thefrog (Gerrit)

unread,

Oct 10, 2025, 1:35:32 PM (2 days ago) Oct 10

to Daniel Rubery, Chromium LUCI CQ, Chromium Metrics Reviews, chromium...@chromium.org, asvitkine...@chromium.org, druber...@chromium.org, net-r...@chromium.org

Attention needed from Daniel Rubery

thefrog voted and added 2 comments

Votes added by thefrog

Code-Review

2 comments

File net/device_bound_sessions/session.cc

Line 398, Patchset 2 (Latest): last_proactive_refresh_opportunity_ = current_timestamp;

thefrog . unresolved

Do these need to get reset sometime? Maybe when there is a deferred request?

File net/device_bound_sessions/session_service_impl.cc

Line 116, Patchset 2 (Latest): minimum_lifetime =

thefrog . unresolved

WDYT about logging the minimum_lifetime itself as part of this CL too? That way we know the lower bound proactive refresh. Extreme example: if most cookie minimum lifetimes are 5 minutes and proactive refresh logs suggest proactively refreshing 4 minutes before expiry is the best, we still wouldn't want to do that necessarily because that would try to refresh every minute.