-
Notifications
You must be signed in to change notification settings - Fork 923
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
feat(blocksync): share.WriteEDS
#1139
Conversation
0a91836
to
03df83b
Compare
share.WriteEDS
share.WriteEDS
Codecov Report
@@ Coverage Diff @@
## main #1139 +/- ##
==========================================
+ Coverage 55.86% 55.92% +0.05%
==========================================
Files 160 161 +1
Lines 9725 9869 +144
==========================================
+ Hits 5433 5519 +86
- Misses 3756 3796 +40
- Partials 536 554 +18
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
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.
Looks correct(besides that byte removal) There is a bunch of optimization that we will have to do eventually, but it's fine for now. Tmrw I will take a deep dive into that bytes mystery and how it works without it. Also, fmt needs to be done in here.
We need to test if it is indexable by DAGStore. Doesn't have to import the whole DAGStore for now and the test can only use car stuff.
The code has a special case for the data with type byte and without. However, it truncates the type byte like it always there. The #1139 is the first user of data without type byte which uncovered the bug. The type byte causes issues for us again.
The code has a special case for the share data with type byte and without. However, it truncates the type byte like it is always there. The #1139 is the first user of share data without a type byte, which uncovered the bug. The type byte causes issues for us again.
0c743f9
to
76241f1
Compare
The code has a special case for the share data with type byte and without. However, it truncates the type byte like it is always there. The #1139 is the first user of share data without a type byte, which uncovered the bug. The type byte causes issues for us again. refactor(ipld/plugin): extract namespaceHasher into a separate file with some additional cleanups In preparation for the upcoming test for the namespaceHasher, we extract it into a separate file. Also, some additional cosmetics were done reducing the API surfuce of the pkg, hiding things that are not supposed to be used outside. test(ipld/plugin): write dummy unit test for the namespaceHasher
The code has a special case for the share data with type byte and without. However, it truncates the type byte like it is always there. The #1139 is the first user of share data without a type byte, which uncovered the bug. The type byte causes issues for us again. refactor(ipld/plugin): extract namespaceHasher into a separate file with some additional cleanups In preparation for the upcoming test for the namespaceHasher, we extract it into a separate file. Also, some additional cosmetics were done reducing the API surfuce of the pkg, hiding things that are not supposed to be used outside. test(ipld/plugin): write dummy unit test for the namespaceHasher docs(ipld/plugin): godocs for the namespaceHasher perf(ipld/plugin): use sha256-simd to gain 40% speedup for hash computations
The code has a special case for the share data with type byte and without. However, it truncates the type byte like it is always there. The #1139 is the first user of share data without a type byte, which uncovered the bug. The type byte causes issues for us again. refactor(ipld/plugin): extract namespaceHasher into a separate file with some additional cleanups In preparation for the upcoming test for the namespaceHasher, we extract it into a separate file. Also, some additional cosmetics were done reducing the API surfuce of the pkg, hiding things that are not supposed to be used outside. test(ipld/plugin): write dummy unit test for the namespaceHasher docs(ipld/plugin): godocs for the namespaceHasher perf(ipld/plugin): use sha256-simd to gain 40% speedup for hash computations
76241f1
to
0237fcb
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.
LGTM. Really have no comments here. Great work.
- We need to hold it off before consolidation is merged and then rebase it on top
- I would still suggest testing indexing explicitly here, but definitely not blocking
- There is a bunch of optimizations(and related refactorings) we can do here, but they are also not blocking and can be done much further
0237fcb
to
04afc9a
Compare
04afc9a
to
4b6e47c
Compare
… of writingSession
Co-authored-by: Viacheslav <viacheslavgonkivskyi@gmail.com>
25977d0
to
8b8ccf3
Compare
Co-authored-by: rene <41963722+renaynay@users.noreply.github.com>
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.
LGTM 🚀
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.
Great work, looks good and clean.
Closes #1105
Still a few todos to be solved and comments to be added, but its ready for the first round of reviews now
Will change the base branch of the PR to the feature branch when it is set up (I will wait until there is preliminary work on it)