-
Notifications
You must be signed in to change notification settings - Fork 48
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
port go tests #159
port go tests #159
Conversation
Given that some blocks will be local and others remote, it is better to start returning as soon as possible. For testing, you can always sort it there. |
@diasdavid as far as I can tell, the previous algorithm was doing the same, no? |
@pgte you seem to be correct. This is a perf optimization that bitswap needs then. |
Before merging this one, could you make sure that this doesn't create any breaking change by going to js-ipfs, npm linking and running unit tests and interop tests? |
@diasdavid interop tests run ok. BTW, this PR is still not done: I was awaiting feedback and then got side-tracked. Back on this! |
@diasdavid except for the |
Also, depends on this for tests to run: libp2p/js-libp2p#138 |
Trying to release libp2p/js-libp2p#138 but npm is not cooperating. Will try again later (or ping me on IRC when you are around) |
released. kicked off CI to start again :) |
Addresses #9, porting go-ipfs bitswap tests into here.
Also, because of making it harder to test, this PR proposes a simplification of the
getMany
implementation. Besides being simpler to track the algorithm, it also guarantees the ordering of returns, i.e., the order of the CIDs passed in is the same order of the respective blocks getting out.This has the downside of the result array having holes in it because of cancelations.
(If this last is a serious breaking change, I could always filter the output before returning).