Ccip-2578 - Enable slow and fast chain #1122
Conversation
| @@ -77,19 +77,17 @@ func (stat *RequestStat) UpdateState( | |||
| step Phase, | |||
| duration time.Duration, | |||
| state Status, | |||
| sendTransactionStats ...TransactionStats, | |||
| sendTransactionStats *TransactionStats, | |||
There was a problem hiding this comment.
Nit: I find naming the argument as optional can help clarify things in cases like this.
| sendTransactionStats *TransactionStats, | |
| optionalSendTransactionStats *TransactionStats, |
| MessageBytesLength: int64(len(msg.Msg.Data)), | ||
| }) | ||
| for _, stat := range rValues.Stats { | ||
| stat.UpdateState(&lggr, 0, testreporters.TX, startTime.Sub(txConfirmationTime), testreporters.Success, nil) |
There was a problem hiding this comment.
Why remove the stats here? Are they no longer important in this context?
There was a problem hiding this comment.
I am storing this stats in SourceLogFinalized step
This is to avoid unnecessary streaming to loki and hoarding data in memory. Otherwise if there is significant load and the msg takes 30-40 min in getting finalized, the memory usage increases due to storing this stats in TX, and CCIPSendReq step. If request fails in TX, and CCIPSendReq step we store the stats, but if it passes these two steps, we just store the relevant data in SourceLogFinalized step to avoid duplication
| NoOfTokensSent: sendRequestedEvent.NoOfTokens, | ||
| MessageBytesLength: int64(sendRequestedEvent.DataLength), | ||
| }) | ||
| reqStat[i].UpdateState(lggr, seqNum, testreporters.CCIPSendRe, 0, testreporters.Success, nil) |
There was a problem hiding this comment.
Is the stat no longer useful here? Or never was?
| txConfirmationTime := time.Now().UTC() | ||
| // wait for the tx to be mined, timeout is set to 10 minutes | ||
| lggr.Info().Str("tx", sendTx.Hash().Hex()).Msg("waiting for tx to be mined") | ||
| ctx, cancel := context.WithTimeout(context.Background(), sourceCCIP.Common.ChainClient.GetNetworkConfig().Timeout.Duration) |
There was a problem hiding this comment.
Removed all of this as we are not capturing how long does it take to confirm a tx. This is a generic chain behavior and can be omitted from validating CCIP specific outcomes.
Motivation
Memory consumption issues when log finalization takes long.
Enabling slow and fast chain to execute in single test.
Deterministic lane creation logic.
Solution
Stop storing successful Tx and CCIPSendReq Phase data in request status if the phases are successful. This will not create unnecessary phase status in memory when SendRequested Log finalization takes time to complete.
To enable fast and slow chain, provide the network details for fast and slow chain in test config. If you want to run all but 3 chains as fast network, you need to provide fast network details in 1st index of test config's
selected_networkand rest of the network as slow config, so that when you provideNoOfNetworksto be greater than provided network number inselected_network, the test can then replicate 1st network config( except chain id) to create rest of the networks (NoOfNetworks- len(selected_network).For example -
If you want to run with 3 slow chains and 5 fast chains, provide network details in this order -
In this way the test will find config for 4 networks and the rest 4 network will be created by replicating 1st network.
MaxNoOfLanesfrom the network pair.