Skip to content

fix: Sync Complete notification firing repeatedly (0.11.1:6)#68

Merged
MattDHill merged 1 commit into
masterfrom
fix/sync-notification-fires-repeatedly
May 24, 2026
Merged

fix: Sync Complete notification firing repeatedly (0.11.1:6)#68
MattDHill merged 1 commit into
masterfrom
fix/sync-notification-fires-repeatedly

Conversation

@helix-nine
Copy link
Copy Markdown

Summary

  • Bug: the Sync Complete notification was firing every few minutes instead of once per install.
  • Cause: startos/main.ts read the store once at setupMain start and captured store in the synced-true oneshot's closure. After the first notification fired, storeJson.merge(effects, { syncNotified: true }) persisted the flag to disk but never refreshed the in-memory store reference. When the sync health check transitioned !success → success again (the bash TCP probe is sensitive enough to flap), HealthDaemon re-fired the oneshot, the captured store.syncNotified was still false, and a new notification was posted. Confirmed in the installed SDK: a oneshot whose requires dep flaps gets restarted via changeRunning(true) → start() → runLoop, re-invoking exec.fn.
  • Fix: read storeJson fresh inside the oneshot's fn so the persisted flag is honored on re-invocations within a single setupMain lifecycle.
  • Release: 0.11.1:5 → 0.11.1:6, renamed in place (no migration); the prior config.yaml → toml migration is carried unchanged.

Test plan

  • npm run check clean
  • make x86 builds electrs_x86_64.s9pk v0.11.1:6
  • Smoke-install on a test box; confirm a single Sync Complete notification appears when the index finishes and no further notifications fire as the sync health check polls (or restarts via bitcoin cookie rotation)

main.ts read store.json once at startup into a closure const and the
synced-true oneshot checked against that snapshot. The SDK's HealthDaemon
re-fires a oneshot every time its dependency dips out of success and
recovers — and the sync health check legitimately flickers (the bash
TCP probe to electrs's Electrum RPC is sensitive enough to blip). Each
re-fire saw the stale snapshot and re-notified even though the on-disk
flag had already been set.

Mirror the LND fix (lnd-startos#162):

- Dedicated sync-notified.json file (the only field in the old store.json
  was syncNotified, so retire store.json with it).
- Read once into a `let notified` closure flag, update alongside the disk
  write. Closure flag is the source of truth within a main lifecycle;
  the on-disk flag re-seeds it across restarts.

Bumps 0.11.1:5 → 0.11.1:6, renamed in place; the prior config.yaml → toml
migration is carried unchanged.
@helix-nine helix-nine force-pushed the fix/sync-notification-fires-repeatedly branch from 24070e2 to c4e964c Compare May 24, 2026 02:45
@helix-nine
Copy link
Copy Markdown
Author

@matthill — you were right. Force-pushed a redo following the LND pattern from lnd-startos#162:

  • Dedicated startos/fileModels/syncNotified.json.ts. (syncNotified was the only field in store.json, so retired store.json along with it.)
  • main.ts reads once into let notified at startup; the oneshot checks the closure flag, posts the notification on first fire, writes sync-notified.json, and sets notified = true. Closure flag is the source of truth within a main lifecycle; the on-disk flag re-seeds it on next startup.

Still 0.11.1:6, still no migration, prior config.yaml → toml migration carried unchanged. npm run check clean, make x86 builds.

@MattDHill MattDHill merged commit 032b998 into master May 24, 2026
1 check passed
@MattDHill MattDHill deleted the fix/sync-notification-fires-repeatedly branch May 24, 2026 03:11
@helix-nine
Copy link
Copy Markdown
Author

Thanks for the review, @MattDHill — shipped as 0.11.1:6.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants