testground's app version is not supported by the versioned module manager

[staheri14]

Problem

To facilitate unbounded block size experiments in e2e tests using knuu, we require to use the testground app version that extends the permissible square size to 512, thereby accommodating block sizes of up to ~126MB. However, the current module manager fails to properly render this app version, resulting in a validator panic when such a version is provided. Specifically, when running SimpleE2ETest with the testground's app version, the validator panics at the outset with the following message (thrown at this line):

panic: version 420420420 not supported

Where 420420420 is the testground app version

More context

The maximum block size is limited by the following factors:

• The versioned constant SquareSizeUpperBound
• The parameter GovMaxSquareSize in the blob's module
• The max_bytes setting in the consensus block parameters

Although the last two parameters can be modified at the time of genesis creation, the first is dependent on the application version. Currently, versions v1 and v2 support a maximum square size of 128, which limits the block size to 8 MB. However, our goal is to increase the block size to 100 MB.

We have previously introduced a testground application version that raises the SquareSizeUpperBound to 512, allowing for block sizes greater than 100 MB. Nonetheless, with the implementation of the versioned module manager, it is now necessary to ensure that the testground application version is also relevant to this module manager. Specifically, there should be a mechanism in versioned module manager to use the latest app version available in the code when the testground app version is seen (that is a potential solution). This capability is currently lacking.

[cmwaters]

In the constructor of the application, each module states the versions it supports and thus the application determines all the versions that it can run over. Given that v2 is just v1 and v2, v420420420 is not supported and thus it panics when genesis provides it an app version that it does not support

[cmwaters]

If we want to have an unbounded test, we could use a different docker image that we build specifically for our tests. This would allow us to make other alterations that aren't available in our official docker image. I believe this was the approach that testground used to take

[staheri14]

If we want to have an unbounded test, we could use a different docker image that we build specifically for our tests. This would allow us to make other alterations that aren't available in our official docker image. I believe this was the approach that testground used to take

So, this means we need to maintain a separate long-lived branch mirroring the main branch with additional modifications for testing purposes only? At this point, I cannot see a lot of such test-related modifications that would motivate having a separate branch except for amending the square size limit. Nevertheless, I am not opposing it, just brain storming.

[cmwaters]

It's a bit difficult to inject code for test purposes in the production binary yet prevent it from users from using it. If we want greater flexibility (for testing sake), perhaps some of these variables shouldn't be hardcoded

[staheri14]

To outline the next steps required to implement this change, following actions seem necessary for a long-term sustainable solution (please let me know your thoughts):

• Create a separate branch dedicated to testing.
• Setting up a bot for backporting changes from the main branch to this testing branch.
• Ensure that an image is generated for every commit in this testing branch and is pushed to https://github.com/celestiaorg/celestia-app/pkgs/container/celestia-app.

As for my current effort to test unbounded block size, I can push an image manually (which I will do), but it is better to aim for a more sustainable long-term solution.

[evan-forbes]

I believe this was the approach that testground used to take

yeah, correct unfortunatley

we had to have this hack

celestia-app/app/module/module.go

Lines 144 to 145 in bce5d07

	if !versionSupported {
	modules = m.versionedModules[appconsts.LatestVersion]

other than that tho, testground is just using the testground specific app version in the genesis

celestia-app/test/testground/network/consensus_node.go

Lines 198 to 204 in 90a5d2d

	tmNode, app, err := testnode.NewCometNode(baseDir, &ucfg)
	if err != nil {
	return err
	}
	cn.cmtNode = tmNode
	cctx := testnode.NewContext(ctx, cn.kr, ucfg.TmConfig, cn.params.ChainID, ucfg.AppConfig.API.Address)

celestia-app/test/testground/network/leader.go

Lines 211 to 218 in 90a5d2d

	return genesis.Document(
	l.ecfg,
	TestgroundConsensusParams(params),
	l.params.ChainID,
	gentxs,
	accounts,
	params.GenesisModifiers...,
	)

celestia-app/test/testground/network/params.go

Lines 184 to 189 in 90a5d2d

	func TestgroundConsensusParams(params *Params) *tmproto.ConsensusParams {
	cp := app.DefaultConsensusParams()
	cp.Block.MaxBytes = int64(params.MaxBlockBytes)
	cp.Version.AppVersion = testgroundconsts.Version
	return cp
	}

[cmwaters]

Create a separate branch dedicated to testing.

We don't necessarily have to have a separate branch. It could be possible to have two binaries within the same codebase (and two docker images for each binary)

[staheri14]

The resolution for the current issue is captured in #3370. Therefore, we can close this one.