Perfect your code
With built-in code review tools, GitHub makes it easy to raise the quality bar before you ship. Join the 36 million developers who've merged over 200 million pull requests.
Sign up for free See pricing for teams and enterprisesdiscovery/sync_manager: restart historical sync on first connected peer #3103
Conversation
halseth
added
discovery
graph
neutrino
test flake
itests
labels
May 21, 2019
halseth
requested a review
from wpaulino
May 21, 2019
wpaulino
approved these changes
May 21, 2019
|
An alternative approach would be to modify the historical sync interval in the integration tests, though I think this is still useful given the following scenario: if you've lost all your peers and start receiving new updates at tip, you won't be able to process some of these channels if you've yet to see their channel announcement, so performing a historical sync before doing so would make sense. LGTM |
| case !initialHistoricalSyncCompleted: | ||
| s.setSyncType(PassiveSync) | ||
| m.inactiveSyncers[s.cfg.peerPub] = s | ||
|
|
||
| // Otherwise, it should be initialized as active. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
| // TestSyncManagerHistoricalSyncOnReconnect tests that the sync manager will | ||
| // re-trigger a historical sync when a new peer connects after a historical | ||
| // sync has completed, but we have lost all peers. | ||
| func TestSyncManagerHistoricalSyncOnReconnect(t *testing.T) { |
This comment has been minimized.
This comment has been minimized.
wpaulino
May 21, 2019
Collaborator
Nit: would prefer if this commit was squashed with what introduced the behavior.
This comment has been minimized.
This comment has been minimized.
halseth
May 24, 2019
Author
Collaborator
I prefer splitting a bugfix and the test reproducing the bug in separate commits. Especially when I'm reviewing this makes it easy to cherry-pick the test commit on master to exercise the failing scenario.
This comment has been minimized.
This comment has been minimized.
wpaulino
May 24, 2019
Collaborator
Sure but that wasn't the case here. The non-test changes alone didn't have an impact on the tests
halseth commentedMay 21, 2019
To handle the case where we have been without peers, and get a new
connection, we reset the historical scan booleans when the first active
syncer is connected to trigger another historical sync.
This would cause integration tests to be flaky (especially with Neutrino), since we would risk not getting graph updates after having being disconnected.