[Bug]: Starting in SDK v0.47, wrong genesis file prevents node startup

[ValarDragon]

Is there an existing issue for this?

• I have searched the existing issues

What happened?

As has been noted many times before, an incorrect genesis file can cause a wrong chain-id to be used, and prevent a node from starting. (e.g. noted here: https://github.com/cosmos/cosmos-sdk/pull/16238/files#r1200247214 )

This is necessary logic for InitGenesis, but should not be the case for nodes restarting / that are already synced.

I could not find a github issue for this, but starting in SDK v0.47, this prevents nodes from starting up, with a failure on this line:

cosmos-sdk/baseapp/abci.go

Lines 155 to 157 in 15259cc

	if req.Header.ChainID != app.chainID {
	panic(fmt.Sprintf("invalid chain-id on BeginBlock; expected: %s, got: %s", app.chainID, req.Header.ChainID))
	}

.

app.chainID is being read from the genesis file, instead of state or a prior block. This is done right here: https://github.com/cosmos/cosmos-sdk/blob/main/server/util.go#L488-L501 . (Unless its overridden via CLI-flag)

This caused some nodes who had the wrong genesis file to fail to start on the osmosis v21.x upgrade to SDK v0.47.x .

It would be nice to get the default chain-id reader to read from state / past blocks, so nodes with the wrong genesis can still restart properly.

Cosmos SDK Version

0.47+

How to reproduce?

You can try starting a node on Osmosis v21.x, with a genesis file containing the wrong chain-id, and no chain-id CLI flag.

You will see:

Dec 18 16:31:08 osmosisd[1661379]: panic: invalid chain-id on BeginBlock; expected: {YOUR GENESIS CHAIN ID}, got: osmosis-1

[alexanderbez]

Since we don't explicitly store the chain-ID in state, although we easily could store v2 (as non-consensus data), I think for now the only way to do this is to get it directly from CometBFT somehow.

[tac0turtle]

If the block store is empty then the value will be unknown until we get the next block. should we allow application developers to set this somewhere in app.go?

[alexanderbez]

I think it's also part of the start command sequence, so it could be pulled from flags (but this is error prone as well)

[tac0turtle]

how was this not an issue before? i cant recall why we changed this?

[julienrbrt]

how was this not an issue before? i cant recall why we changed this?

We needed the chain-id for Prepare/Process proposal: #15269

[atheeshp]

this is not a bug in main, 0.50.x, tested locally working fine. But this bug exists in only 0.47.x.
just raised a fix for 0.47.x #18920

[tac0turtle]

fixed in #18920