Conversation
gakonst
left a comment
There was a problem hiding this comment.
@rakita good start, I think before merging this, would like to understand exactly where the point of integration with the rest of the code will be? is it going to be engine api? how are we going to expose a single block to get executed?
| _provider: &PROVIDER, | ||
| _consensus: &CONSENSUS, |
There was a problem hiding this comment.
The provider & consensus should prob be part of the struct?
Let's move this discussion to the main task, it will get dissolved if we start discussion it on two places. |
gakonst
left a comment
There was a problem hiding this comment.
Took another pass and looking nice. I think you already know this but let's add a few tests around insert/make-canonical for a few of the scenarios you mention, to make sure we handle things correctly.
I think we'll probably end up doing insert_chain on each new_payload and then on fork_choice_updated we'll be "flushing", which realistically means having the headers+bodies+execution stage run for that part.
Yeah, testing is completely missing and some TODO are pending. I wanted to make a draft so that @rkrasiuk can see what is found inside and how it can be used. |
|
@rakita i will take some time today to review this, thanks! |
rkrasiuk
left a comment
There was a problem hiding this comment.
in general, the interface looks good. didn't do an in-depth review of the implementation. leaving couple of questions
50924bc to
43556de
Compare
rkrasiuk
left a comment
There was a problem hiding this comment.
@rakita this implementation is safe if it will be invoked exclusively by the engine API, because the latter is implemented as a Future and consumes the requests successively. otherwise, i believe, we would need some lock mechanism to prevent concurrent operations on the blockchain tree
2e67384 to
ef3be7e
Compare
87f66af to
e794bfb
Compare
e794bfb to
65e56b4
Compare
287e067 to
79c3e03
Compare
1806404 to
3eb05ff
Compare
mattsse
left a comment
There was a problem hiding this comment.
I think I understand the internals.
I didn't review very closely but I could kinda follow along.
test coverage looks great.
perhaps I'm being a bit pedantic, but I want to emphasize that we likely don't want pub field access for most of the things.
| use std::ops::DerefMut; | ||
|
|
||
| #[test] | ||
| fn insert_get_take() { |
There was a problem hiding this comment.
There are way too few tests here considering everything in the stages crate has been moved here at this point.
There was a problem hiding this comment.
What is moved from stage still gets tested from it. With test data i tried to cover cases that can happen in both getting and taking data from database, and additionally, BlockchainTree is testing this functionality in its own way.
There was a problem hiding this comment.
As part of the refactor of the Transaction struct during our tech debt cleanup, we should introduce more tests
rkrasiuk
left a comment
There was a problem hiding this comment.
leaving some minor comments and cautiously approving. well done overall! just a lot of moving parts here and we've done multiple passes at this over the last couple of days
|
@rakita pending conflict resolution |
|
@rakita some tests seem to be failing |
rkrasiuk
left a comment
There was a problem hiding this comment.
lessssssgoooooooooooooooooooooooooooooooooooo
gakonst
left a comment
There was a problem hiding this comment.
sweet. nice work on the tree tester, was really missing. let's ship it and iterate as we get closer to SyncController + Engine API tests on Hive
closes: #1104