-
Notifications
You must be signed in to change notification settings - Fork 32
Fix sync rate not showing #385
Conversation
}) | ||
// Emit "not synced" only if we haven't been synced for over 2 seconds | ||
) | ||
.pipe(audit(syncStatus => interval(syncStatus.isSync ? 0 : 2000))), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm, I don't get the difference between before and after
Before: on each syncStatus update, do:
- if we're synced, then show that we're synced
- if we're syncing, then wait 2s, then show that we're syncing (if we're still syncing after those 2s).
And new version: on each syncStatus update, do:
- wait 0s if we were synced, then show syncStatus
- wait 2s if we were syncing, then show syncStatus
Maybe I don't understand audit enough. Does it play the same role as delay here?
ps: would appreciate @axelchalon's eyes on this too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Before: on each syncStatus update, do:
- if we're synced, then show that we're synced
- if we're syncing, then wait 2s to emit. The emission is reset if
syncStatus
updates in the mean time (that's the problem).
And new version: on each syncStatus update, do:
- wait 0s if we were synced, then show syncStatus
- wait 2s if we were syncing, then show the most recent syncStatus value.
The main difference is that audit
will emit anyway (with the most recent value), delay
will not necessarily emit. Note that throttle
sits in between and would emit anyway, but with a not up to date value.
BTW I have to thank @axelchalon who helped me debug and find this solution 💚
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah nice! got it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the root of the problem was the reasoning
// syncStatus$() is distinctUntilChanged, so {isSync: false} will never be fired twice in a row.
which was false, because syncStatus$() returns {isSync: false, currentBlock: ..., highestBlock: ..., startingBlock: ...}
so even though it's distinct until changed it might emit {isSync: false, ...}
multiple times in a row
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice job investigating this! 🎉
syncStatus$
was emitting severalisSync: false
more frequently than 2s because the blocks (also part ofsyncStatus$
) were changing. This preventedrpc$
to be emitting and the UI to be updated.audit
allows to delay the emission of an event of 2s when not synced. The down side of this solution is that when syncing we only get the sync rate every 2s.