fix: avoid querying to refresh types in the ServiceBrowser when they are seen after scheduling by bdraco · Pull Request #1171

fix: avoid querying to refresh types in the ServiceBrowser when they are seen after scheduling by bdraco · Pull Request #1171 · python-zeroconf/python-zeroconf

The ServiceBrowser query scheduling was suboptimal because it would reschedule to query for a type when 75% of the ttl was expired, but if the type was seen before the timer expired we would send the query anyways which created more network traffic

fixes #821

…are seen after scheduling

The ServiceBrowser query scheduling was sub-optimial because it would
reschedule to query for a type when 75% of the ttl was expired, but
if the type was seen before the timer expired we would send the query
anyways which created more network traffic

fixes #821

Comment on lines 995 to +998

		delay = const._BROWSER_TIME
		types_ = {"_hap._tcp.local.", "_http._tcp.local."}
		query_scheduler = _services_browser.QueryScheduler(types_, delay, (0, 0))
		cache = DNSCache()
		query_scheduler = _services_browser.QueryScheduler(cache, types_, delay, (0, 0))

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need another query scheduler test that interacts with a populated DNSCache before we can merge this

Was trying to fix this before the issue hit the 2 year mark, but out of time to write the test for today

The integration test is going to need to set the test PTR record cache to be almost expired as its already way too complex and we don't want to test that there.

We will pickup the coverage in the query scheduler tests

The problem is we need two timers.

Once for the regular "next_time" and one for "min_time_to_save_record" so reschedule only affects the second one and we already still do the next_time

The downside is that if the network drops for a bit we might not refresh in time but thats probably not a problem since it will eventually recover