test: allow producing block on top of arbitrary prev block #10093
Conversation
| @@ -3044,6 +3049,12 @@ fn test_fork_receipt_ids() { | |||
| env.clients[0].process_block_test(block.clone().into(), Provenance::NONE).unwrap(); | |||
| } | |||
|
|
|||
| // Ensure that in stateless validation protocol receipts in fork blocks are executed. | |||
| let b3 = env.clients[0].produce_block_on(last_height + 3, *block1.hash()).unwrap().unwrap(); | |||
There was a problem hiding this comment.
nit: block3 and block4 since that's how 1 and 2 are, for uniformity?
|
Ah, finally, near gets proper support for forks, a feature long awaited by the community :) |
| @@ -477,20 +477,19 @@ impl Client { | |||
|
|
|||
| fn should_reschedule_block( | |||
There was a problem hiding this comment.
While you're at it, can you add some comments please?
There was a problem hiding this comment.
Will do in following PR.
| height: BlockHeight, | ||
| prev_hash: CryptoHash, |
There was a problem hiding this comment.
So just for my understanding, height and prev_hash are not tied together are they? As in height can be arbitrary number as long as it is greater than the height of the block with hash prev_hash.
There was a problem hiding this comment.
Depends on what you mean by "tied together". Yeah, height is not necessarily height(prev_hash)+1 anymore, but prev_hash is still hash of previous block for block being produced.
|
To be completely clear, after that clients still will not produce blocks for arbitrary heights during normal production behaviour. It is test-only feature. |
For stateless validation, chunk execution will be delayed until next block is processed: #9982. This impacts several tests assuming that block processing includes chunk processing as well. For these tests, we need to produce and process one more block to get execution results like ChunkExtra and ExecutionOutcome.
To allow production of longer forks, I want to extend client API by
produce_block_onwhich can produce a block not just on top of head, but on top of any existing block. As this block isn't immediately saved or processed, it even doesn't break any guarantees.Testing
Impacted tests should still pass. Later stateless validation PRs will rely on it.