feat(grpc): resigning and resubmission of transactions #768
Conversation
zvolin
force-pushed
the
feat/grpc-parallel-submit
branch
from
6a10cb5 to
b435cf6
Compare
|
|
||
| # This validator is started as a separate network, only to be able to test | ||
| # transactions eviction cases. Thus it has low TTL and block size. | ||
| validator-eviction-testing: |
There was a problem hiding this comment.
I think validators should be grouped together, but not feeling too strongly about it.
There was a problem hiding this comment.
I moved it to the bottom because it's completely separate network, but no strong feelings too
| environment: | ||
| - NODE_NAME=validator-eviction-testing | ||
| # amount of DA nodes to provision (default: 3) | ||
| - NODE_COUNT=3 |
There was a problem hiding this comment.
Does it mean that both validators will send the funds?
There was a problem hiding this comment.
yes, because the networks are separated, accounts need funding on both
There was a problem hiding this comment.
thanks! shared secret keys and separate networks threw me off initially. Would you mind adding small comment like
This creates a separate private network, with the same accounts provisioned
or something to that effect
Co-authored-by: Mikołaj Florkiewicz <[email protected]> Signed-off-by: Maciej Zwoliński <[email protected]>
| pub struct TestAccount { | ||
| /// Bech32 `AccountId` of this account | ||
| pub address: Address, | ||
| #[allow(dead_code)] |
There was a problem hiding this comment.
Move this below the doc comment
|
|
||
| if let Some(new_sequence) = res.as_ref().err().and_then(extract_sequence_on_mismatch) { | ||
| account.base.sequence = new_sequence?; | ||
| continue; |
There was a problem hiding this comment.
This goes back to sign_tx, shouldn't we recalculate gas?
|
|
||
| if let Some(new_sequence) = res.as_ref().err().and_then(extract_sequence_on_mismatch) { | ||
| account.base.sequence = new_sequence?; | ||
| continue; |
| // we need to revert the account sequence to that of the rejected tx. | ||
| TxStatus::Rejected => { | ||
| let mut acc = self.lock_account(context).await?; | ||
| acc.base.sequence = sequence; |
There was a problem hiding this comment.
Is the following possible?
- User starts 3 submissions
- They got signed and broadcasted sequencally, lets say their sequence numbers are: 101, 102, 103
- On the confirm_tx, we get the replies with this order: 102, 101, 103
- The
base.sequencebecames 103, but in reality it should be the lowest evicted.
3 participants
No description provided.