FIX(Archive.Processor): ensure add_block_aux is always adding block d…#18091
FIX(Archive.Processor): ensure add_block_aux is always adding block d…#18091glyh wants to merge 2 commits into
Conversation
|
!ci-nightly-me |
…ata in 1 single txn
e638b28 to
ab6f53a
Compare
|
!ci-nightly-me |
| add_block_aux ~logger ?retries ~pool ~delete_older_than | ||
| ~add_block: | ||
| (Block.add_from_precomputed ~logger ~proof_cache_db ~constraint_constants) | ||
| (Block.add_from_precomputed ~logger ~proof_cache_db ~constraint_constants |
There was a problem hiding this comment.
The ugliness here comes from the fact add_block_aux is used for 3 different case making this interface hard to change.
| in | ||
| (* NOTE: it's fine for accounts_accessed to be added non-atomically. | ||
| Since we're bootstrapping, I guess? *) | ||
| (* TODO: figure out whether we need to add genesis accounts to accounts_created *) |
There was a problem hiding this comment.
Actually this is interesting also from HF. If we have data from before hf and maybe from the start of blockchain then we have full history of all accounts.
However if we are starting archive from latest hf, we don't . So this could be a nice way to fill those gaps.
There was a problem hiding this comment.
That sounds good, but I assume it should go into another PR
There was a problem hiding this comment.
This one is a curious thing. In practice, I think it's fine to have ~accounts_accessed:[] ~accounts_created:[]. I can't imagine (as of now) a flow where we'd be creating some accounts in a HF.
In theory the code allows that, but in practice this won't ever be happening.
|
@glyh Is this change covered with unit/functional tests ? To truly verify fix i would imagine we write reproduction unit test which is failing on this special case we are fixing in your PR. Then we ensures that this implementation fixes mentioned test. Otherwise, we are a bit wandering in the dark. |
|
This bug is a race condition, we need to think of a proper way add test. |
| in | ||
| (* NOTE: it's fine for accounts_accessed to be added non-atomically. | ||
| Since we're bootstrapping, I guess? *) | ||
| (* TODO: figure out whether we need to add genesis accounts to accounts_created *) |
There was a problem hiding this comment.
This one is a curious thing. In practice, I think it's fine to have ~accounts_accessed:[] ~accounts_created:[]. I can't imagine (as of now) a flow where we'd be creating some accounts in a HF.
In theory the code allows that, but in practice this won't ever be happening.
|
Is it okay to merge, now George has implemented tests? @dkijania |
|
!ci-build-me |
|
!ci-build-me |
|
Close in favor of #18132 |
…ata in 1 single txn