-
Notifications
You must be signed in to change notification settings - Fork 134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: remove legacy_ibc_testing
folder
#1003
chore: remove legacy_ibc_testing
folder
#1003
Conversation
- Ensure a minimal staking module is present - Ensure the consumer module contains the provider valset
@tbruyelle Thank you for your contribution. As you have noted above, I will look further into this, but as far as I can tell, we will need to port over some of the changes in behaviour. Do you mind if we merge this after we get The reason being is that we still need to test if v47 integrates with main (we need a working test suite for that) and we will probably need to keep some of the changes to |
@MSalopek no problem, because this PR is not merge-able until this diff is applied to diff --git a/testing/chain.go b/testing/chain.go
index 928941d4..c4f21507 100644
--- a/testing/chain.go
+++ b/testing/chain.go
@@ -279,15 +279,15 @@ func (chain *TestChain) NextBlock() {
chain.App.Commit()
- // set the last header to the current header
- // use nil trusted fields
- chain.LastHeader = chain.CurrentTMClientHeader()
-
// val set changes returned from previous block get applied to the next validators
// of this block. See tendermint spec for details.
chain.Vals = chain.NextVals
chain.NextVals = ApplyValSetChanges(chain.TB, chain.Vals, res.ValidatorUpdates)
+ // set the last header to the current header
+ // use nil trusted fields
+ chain.LastHeader = chain.CurrentTMClientHeader()
+
// increment the current header
chain.CurrentHeader = tmproto.Header{
ChainID: chain.ChainID, |
@tbruyelle awesome stuff! This is a change I've been looking forward to for a while. This will be a draft PR for now |
Thank you <3 |
@tbruyelle have you had a chance to make a PR to ibc-go? I agree that this is a great change! |
No, I wait for approval here, then I'll submit the change to ibc-go. |
I apologize in advance for the length of this PR, but a thorough read will significantly aid the code review process.
Description
As indicated in the code comments of the
legacy_ibc_testing
folder, this folder was meant to be removed following the IBC upgrade. In the context of the IBC v7 upgrade, I decided to tackle this task.The process was not as straightforward as anticipated, because the
legacy_ibc_testing
is not merely a copy of theibc-go/testing
folder. It contains numerous adaptations related to ICS. I managed to address all of them except one, which is why some tests still fail, all for the same reason (see the valset/header update order section for details).Here is a list of changes, categorized into three sections for easier readability: Minor changes, Consumer genesis updates, Packet sniffing, and finally, Valset/header update order.
Minor changes
legacy_ibc_testing
folder, replace all imports fromgithub.com/cosmos/interchain-security/legacy_ibc_testing
togithub.com/cosmos/ibc-go/v7/testing
.ibctesting.NewTestChain
no longer accepts theappIniter
. This must be assigned toibctesting.DefaultTestingAppInit
before callingNewTestChain
(see documentation).endpoint.SendPacket
API now requires packet data and timeout values instead of a packet (see related PR).ibctesting.TestingApp.GetStakingKeeper()
no longer gives access toUnbondingTime()
method: replace withGetTestStakingKeeper()
.ibcsimapp.CreateTestPubKeys
byibctesting.GenerateKeys
icstestingutil.ReconstructPacket
byibctesting.ParsePacketFromEvents()
ibctesting.GetChainID()
now returns by default a chainID with a revision, which wasn't expected by the tests. Disable it by settingibctesting.ChainIDSuffix = ""
.Consumer genesis updates
In consumer chains, the validator set is not expected to be find in the
staking
module, but rather in theconsumer
module. This was previously handled inSetupWithGenesisValSet
, which feeds the consumer genesis with the valset passed in parameters.With the removal of
legacy_ibc_testing
, it's no longer possible to adaptSetupWithGenesisValSet
in this way. Therefore, I adopted a different approach. I modified the consumer and consumer-democracy appIniter to accept a valset parameter (I introduced avalSetAppIniter
), and they populate their genesis from this valset (sinceappIniter
also returns the genesis).When calling consumer
appIniter
, the provider valset is passed in parameters, while when calling consumer-democracyappIniter
, the valset created in the test is passed.Similarly,
SetupWithGenesisValSet
expects astaking
module entry in the genesis, which is not the case for a consumer chain. This was previously handled by checking if astaking
entry was present in the genesis (see here). For the same reason, I had to find a workaround, and so I also updated the consumer appIniter so its genesis contains a placeholderstaking
entry.Packet sniffing
The
legacy_ibc_testing
was adapted to record all packets in a map field ofTestChain
(see here). This field doesn't exist in theibc-go/v7/testing
, so I updated theCCVTestSuite
struct to add aStreamingService
implementation calledpacketSniffer
to all created chains. ThepacketSniffer
listens toEndBlock
and appends all packets parsed from events.Valset/header update order
In
legacy_ibc_testing
, theTestChain.NextBlock
looks like that :In
ibc-go/v7/testing
, it's a little different :The validators are updated after the
chain.LastHeader
update, which makes theUpdateClient
call fail, because the trusted validators hash doesn't match the consensus state next validators hash (can't give more explanations because I lack knowledge on IBC).If we change the order like it was in
legacy_ibc_testing
theUpdateClient
works well.For this one I wasn't able to find a workaround, probably a PR should be submitted to
ibc-go
to change that order. I ran theibc-go
tests with that change and there's still green, so that looks fine. Or else maybe someone can find a workaround ?Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...
!
to the type prefix if API or client breaking changeCHANGELOG.md
Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...
!
in the type prefix if API or client breaking change