-
Notifications
You must be signed in to change notification settings - Fork 26
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
Pipelining followups #147
Pipelining followups #147
Conversation
…from fileReadWrite_test.go
Co-authored-by: shiqizng <[email protected]>
Codecov Report
@@ Coverage Diff @@
## master #147 +/- ##
==========================================
+ Coverage 67.66% 72.89% +5.23%
==========================================
Files 32 38 +6
Lines 1976 2789 +813
==========================================
+ Hits 1337 2033 +696
- Misses 570 646 +76
- Partials 69 110 +41
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
|
||
<-p.ctx.Done() |
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.
This is the health endpoint bugfix.
} | ||
|
||
func (imp *noopImporter) GetBlock(rnd uint64) (data.BlockData, error) { | ||
time.Sleep(sleepForGetBlock) |
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.
Why the sleep?
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.
Just to slow down the pipeline. For example, if you have a no-op for your importer and a file-writer for your exporter this limits the output to 10 blocks per second which is a little easier to manage than without having any sort of brakes on. Another option is to make this configurable, but that didn't strike me as ideal either since I'd like the no-op importer to have no config. LMK.
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.
Approved pending your offer to remove the unused function.
|
Summary
Addressing the Pipelining Followups Issue along with the "CLI health endpoint bug" which I discovered while working on the block generator.
The CLI Health Endpoint Bug
This bug was actually introduced by the Pipelining PR which preceded the health endpoint, and in particular this line which caused
Start()
itself to wait forever. As a consequence, the setup of the health endpoint was never reached while conduit was running.Issue
#141
TODO's
retriesNoOutput()
and its test, unless a use case for this PR comes up.Testing
Introducing
TestHealthEndpoint()
incli_test.go
for checking that the health endpoint is ON/OFF as configured. I verified that when the bug is re-introduced, theAPI_ON
case fails as expected. For the purposes of the test, I also introduced anoop importer
which waits 100 ms before returning in itsGetBlock()
method.