-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
algod importer: Combines algod and algod_follower #1452
Conversation
ab07699
to
2daa8a7
Compare
Codecov Report
@@ Coverage Diff @@
## develop #1452 +/- ##
===========================================
- Coverage 65.28% 65.16% -0.13%
===========================================
Files 83 81 -2
Lines 11452 11369 -83
===========================================
- Hits 7477 7409 -68
+ Misses 3404 3395 -9
+ Partials 571 565 -6
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
Resolves #1449 Combines the algod and algod_follower plugins and uses a config value to switch between the logic of them
2daa8a7
to
01b06eb
Compare
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.
Two main changes:
- Find a way to avoid a string comparison to toggle functionality in the GetBlock path.
- Fix the tests. It looks like you applied the same pattern blindly to all tests. Most of them don't seem to add any coverage, the ones that do don't have any new assertions to check that the functionality is correct.
13900c2
to
a26e476
Compare
a26e476
to
b46cb57
Compare
…od-based-plugin-logic
…od-based-plugin-logic
@@ -155,23 +155,18 @@ func (algodImp *algodImporter) GetBlock(rnd uint64) (data.BlockData, error) { | |||
var blk data.BlockData | |||
|
|||
for retries := 0; retries < 3; retries++ { | |||
// nextRound - 1 because the endpoint waits until the subsequent block is committed to return |
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.
I'm wondering if this retry loop is necessary. there's already retries at the pipeline level. in this loop there's no wait before the next try, could this loop always finish before the next block is available?
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.
Yep, just added retires w/ backoff to the most recent version.
for r := 0; r < retries; r++ {
time.Sleep(time.Duration(waitMultiplier*float64(r)) * initialWait)
...
We could just rely on the pipeline-level retires like you said, but retries with backoff make more sense in the case of the follower node since the catchup service gets started/stopped so frequently.
Resolves #1449
Combines the algod and algod_follower plugins and uses a config value to switch between the logic of them