An /update run leaves a marker naming the chat to notify. When that platform's
adapter is not connected as the update finishes, _send_update_notification
defers and keeps the markers for a later retry — correct for the restart that
/update itself triggers, where the adapter reconnects seconds later.
Nothing bounds that wait. If the platform is not configured at all, no adapter
will ever appear and the defer never resolves. The startup path reschedules the
watcher whenever the markers are still on disk, so the marker outlives every
restart: it re-logs "adapter not connected yet" each poll_interval (2s), in
every process, indefinitely. A marker written months ago was still doing this
on one install, filling gateway.log with ~19k duplicate lines.
Bound the wait using the timestamp the marker already carries. Once the marker
is older than the cap the notice is undeliverable by any retry, so log it once
at WARNING, clear the markers, and return True — the definitive answer that
stops the caller rescheduling. Markers with no timestamp (written before that
field existed) keep the previous retry behavior rather than guess an age.
Tests cover the three behaviors: a stale marker is dropped and clears every
marker file, a recent marker is still held for the reconnecting adapter, and a
marker without a timestamp still retries.
601a8a17c2