Context

Hey! We think there might be a bug in Cosmos SDK. A few months ago, a constant MaxUnpackAnySubCalls‎ = 100 was added, which - if we understand correctly - sets a limit on the number of calls inside MsgExec. However, in this transaction (link), there seem to be around 175 calls. As a result, when trying to parse the transaction, we get a call limit exceeded error. For now, we’ve rolled back to version v1.25.0-sdk-v0.46.16, where this change wasn’t present. But if there are breaking changes in the future, we won’t be able to re-index using the newer versions. Is this expected behavior or a bug? And what would be the best way to handle this?

From @vvuwei

Problem

v1.25.1-sdk-v0.46.16 included a fix that addressed a security vulnerability but celestia-app releases with that change won't be able to process block 7013 because this tx has more than 100 UnpackAny calls. This effectively breaks single-binary syncs.

Options

1. Identify txs included on-chain with a UnpackAny >= 100. If it's not that many, consider modifying the constant in celestia-app v4 to handle the max UnpackAnys already included on-chain.
2. Consider wrapping fix: transaction decoding may result in a stack overflow or resource exhaustion cosmos-sdk#422 in a version gate so that it only applies to app version >= 3
3. Consider wrapping fix: transaction decoding may result in a stack overflow or resource exhaustion cosmos-sdk#422 in a block height gate so that it only applies to block heights >= N