InitializeTestLCD timeouts when nValidators > 1

[fedekunze]

Summary of Bug

Can't run test LCD on because it timeouts when setting out nValidators > 2

Steps to Reproduce

On client/lcd/lcd_test.go I defined:

cleanup, pks, port := InitializeTestLCD(t, 2, []sdk.AccAddress{addr})

Which after 60s timeouts:

E[09-14|13:03:51.561] Couldn't connect to any seeds                module=p2p 
LADDR tcp://0.0.0.0:54870
E[09-14|13:04:21.565] Couldn't connect to any seeds                module=p2p
Tests timed out after 60000ms

After printing different steps in the code it seems that the error comes from this part of the function:

cosmos-sdk/client/lcd/test_helpers.go

Lines 190 to 193 in b5f8350

	node, err := startTM(config, logger, genDoc, privVal, app)
	require.NoError(t, err)
	tests.WaitForNextHeightTM(tests.ExtractPortFromAddress(config.RPC.ListenAddress))

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[mossid]

GaiaAppGenState allocates equal power to initial validators:

cosmos-sdk/cmd/gaia/app/genesis.go

Line 200 in 416181b

validator, stakeData.Pool, issuedDelShares = validator.AddTokensFromDel(stakeData.Pool, freeFermionVal)

So node does not start when nValidator > 1. Also see #1373 (comment).

I think we can write something like TestGaiaAppGenState, which allocates voting power depending on its input.

[fedekunze]

@mossid also genesis.go has a very low test coverage (51.2%)

[alexanderbez]

So ended up digging a long time into this (both TM SDK) and @mossid is correct, It boils down to GaiaAppGenState (because init chainer on TM relay gets called which sends the app state that has equal power for each validator). So I'll be writing a test version of that.

Also throughout this process, I've realized the genesis logic and implementation as well as the higher level commands calling it, is pretty convoluted, messy and complex.