Periodic adverts never fire when the daemon restarts more often than the interval #141

New Issue

2026-10-27T09:35:16+01:00

adam commented

2026-10-27 09:35:16 +01:00

Symptom

repeater.send_advert_interval_hours (and the room/direct advert streams) start their cadence at daemon start — the first periodic advert is sent one full interval after boot (_periodic_advert_due: "Streams start their cadence at daemon start"). Any deployment that restarts the daemon more often than the interval (nightly image updates, watchdogs, config pushes) therefore never adverts at all.

Evidence

Our observer node ran with send_advert_interval_hours: 48 and a daily container-update restart. Its last advert on the community analyzer was 4 days old before we noticed; every restart silently reset the 48 h countdown. (The node was healthy the whole time — only discovery suffered: analyzers age nodes out of the map without fresh adverts.)

Suggestion

Either (or both):

persist the per-stream last_sent timestamp (storage is already there) so a restart resumes the cadence instead of resetting it, or
an opt-in advert_on_start (first advert N minutes after boot, then the normal interval).

Workaround today: POST /api/send_advert from a cron/systemd timer, which works but duplicates scheduling the daemon already owns.

## Symptom `repeater.send_advert_interval_hours` (and the room/direct advert streams) start their cadence at daemon start — the first periodic advert is sent one **full interval after boot** (`_periodic_advert_due`: "Streams start their cadence at daemon start"). Any deployment that restarts the daemon more often than the interval (nightly image updates, watchdogs, config pushes) therefore **never adverts at all**. ## Evidence Our observer node ran with `send_advert_interval_hours: 48` and a daily container-update restart. Its last advert on the community analyzer was 4 days old before we noticed; every restart silently reset the 48 h countdown. (The node was healthy the whole time — only discovery suffered: analyzers age nodes out of the map without fresh adverts.) ## Suggestion Either (or both): - persist the per-stream `last_sent` timestamp (storage is already there) so a restart resumes the cadence instead of resetting it, or - an opt-in `advert_on_start` (first advert N minutes after boot, then the normal interval). Workaround today: `POST /api/send_advert` from a cron/systemd timer, which works but duplicates scheduling the daemon already owns.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/pyMC_Repeater#141