fix: Sync Complete notification firing repeatedly (0.11.1:6)#68
Merged
Conversation
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.
24070e2 to
c4e964c
Compare
Author
|
@matthill — you were right. Force-pushed a redo following the LND pattern from lnd-startos#162:
Still 0.11.1:6, still no migration, prior |
MattDHill
approved these changes
May 24, 2026
Author
|
Thanks for the review, @MattDHill — shipped as 0.11.1:6. |
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
startos/main.tsread the store once atsetupMainstart and capturedstorein thesynced-trueoneshot's closure. After the first notification fired,storeJson.merge(effects, { syncNotified: true })persisted the flag to disk but never refreshed the in-memorystorereference. When thesynchealth check transitioned !success → success again (the bash TCP probe is sensitive enough to flap),HealthDaemonre-fired the oneshot, the capturedstore.syncNotifiedwas stillfalse, and a new notification was posted. Confirmed in the installed SDK: a oneshot whoserequiresdep flaps gets restarted viachangeRunning(true) → start() → runLoop, re-invokingexec.fn.storeJsonfresh inside the oneshot'sfnso the persisted flag is honored on re-invocations within a singlesetupMainlifecycle.config.yaml → tomlmigration is carried unchanged.Test plan
npm run checkcleanmake x86buildselectrs_x86_64.s9pkv0.11.1:6synchealth check polls (or restarts via bitcoin cookie rotation)