Closed Jorropo closed 3 years ago
Thank you for submitting this PR! A maintainer will be here shortly to review it. We are super grateful, but we are also overloaded! Help us by making sure that:
The context for this PR is clear, with relevant discussion, decisions and stakeholders linked/mentioned.
Your contribution itself is clear (code comments, self-review for the rest) and in its best form. Follow the code contribution guidelines if they apply.
Getting other community members to do a review would be great help too on complex PRs (you can ask in the chats/forums). If you are unsure about something, just leave us a comment. Next steps:
A maintainer will triage and assign priority to this PR, commenting on any missing things and potentially assigning a reviewer for high priority items.
The PR gets reviews, discussed and approvals as needed.
The PR is merged by maintainers when it has been approved and comments addressed.
We currently aim to provide initial feedback/triaging within two business days. Please keep an eye on any labelling actions, as these will indicate priorities and status of your contribution. We are very grateful for your contribution!
/cc @dirkmc (no idea if you are interessed but you wrote 47b99b1ce34a8add8e5f38cf2eec6bea1559b035 :))
@coryschwartz : we're hoping you can take a quick look at this as it may be reviewable without go-bitswap context. If you think you need more, then leave it for @aschmahmann .
Failing tests are unrelated.
This option is used by the benchmark to simulate the old bitswap comportement (and fixes the benchmark).
This follows the same refactoring idea as done in 47b99b1ce34a.
It was crashing since it was trying to access the
sendDontHaves
property ofbs.engine
butbs.engine
is initialized right after the options are applied, not before.Unlike 47b99b1ce34a, I've choosed to not make
sendDontHaves
part of engine's constructor because this is such an obscure option, useless in +99% of realworld scenario that it's not needed to confuse the engine contructor.