const LAN_PEER_STALE_TIMEOUT_FLOOR_SECS: u64 = 300;Expand description
How long a peer is kept after its most recent ServiceResolved before
get_instances() treats it as gone. mdns-sd’s own ServiceRemoved event
is NOT used for this (see the ServiceRemoved arm of handle_event
below) — live logs showed it firing on ordinary TTL churn seconds before
the same peer re-resolved, and every re-resolution after a remove() came
back with a blank TXT record, so deleting on ServiceRemoved permanently
wiped a live peer’s hostname/instance_id/version/auth_key for no real
disappearance.
This is a FLOOR, not the actual timeout — see peer_staleness_window_secs.
A fixed 300s (this constant’s original, only value — see
docs/retro/retro-lan-peer-stale-timeout-too-short-for-slow-reannounce-peers-2026-09-17.md)
was tuned against one fast-reannouncing peer seen in live logs (1-2 minute
re-fire gaps) and wrongly pruned peers whose own advertised record TTL is
much longer: RFC 6762 §10’s recommended (and mdns-sd 0.12’s hardcoded,
unconfigurable-from-this-crate-version) default other_ttl for PTR/TXT
records is 4500s/75min, and real LAN peers were observed re-announcing on
gaps up to ~46 minutes — comfortably inside that TTL, but 9x past the old
fixed cutoff. 300s remains only as a safety floor against a peer that
somehow advertises an implausibly small TTL.