fix: revert tx when block gas limit exceeded (backport: #10770)

[yihuang]

Description

backport from #10770, but used a different solution from the master one, because of difference in code structure.

---

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...

• included the correct type prefix in the PR title
• added ! to the type prefix if API or client breaking change
• targeted the correct branch (see PR Targeting)
• provided a link to the relevant issue or specification
• followed the guidelines for building modules
• included the necessary unit and integration tests
• added a changelog entry to CHANGELOG.md
• included comments for documenting Go code
• updated the relevant documentation or specification
• reviewed "Files changed" and left comments if necessary
• confirmed all CI checks have passed

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...

• confirmed the correct type prefix in the PR title
• confirmed ! in the type prefix if API or client breaking change
• confirmed all author checklist items have been addressed
• reviewed state machine logic
• reviewed API design and naming
• reviewed documentation is accurate
• reviewed tests and test coverage
• manually tested (if applicable)

[amaury1093]

oh nice, thanks a lot. I'm putting in draft for now, let's merge #10770 first.

[yihuang]

I guess we better write a unit test for this too, but I find it not easy to do that? which test suite is the best place to write a test case for this?

[yihuang]

no need to check overflow since it's already handled in ConsumeGas.

[amaury1093]

this seems correct to me, @yihuang did you think of how we can write a test for this?

Edit: maybe in TestMaxBlockGasLimits in baseapp_test?

[amaury1093]

Can we remove this defer func?

AFAIK, there's no gas consumption after runMsgs. So if we put consumeBlockGas in runTx, before store write, then it should be okay?

[yihuang]

We need defer function to consume block gas when panic happens I think.

[amaury1093]

Okay, let's maybe keep it for now

[yihuang]

this seems correct to me, @yihuang did you think of how we can write a test for this?

Edit: maybe in TestMaxBlockGasLimits in baseapp_test?

I tried before, find it very tedious to set up the environment, let me try it again.

[yihuang]

this seems correct to me, @yihuang did you think of how we can write a test for this?

Edit: maybe in TestMaxBlockGasLimits in baseapp_test?

We can't do that in baseapp_test, because baseapp module is imported by keeper, if we setup keepers, it'll cause cyclic import. we need to use sth like SimApp.

[yihuang]

this seems correct to me, @yihuang did you think of how we can write a test for this?

Edit: maybe in TestMaxBlockGasLimits in baseapp_test?

tests added.

[amaury1093]

thanks a lot

Let's get this released today 😎

[robert-zaremba]

utACK, left few tiny comments.

[robert-zaremba]

do we need to call it here? It's already called in defer (line 614)

[yihuang]

do we need to call it here? It's already called in defer (line 614)

That's the main purpose of this PR, call it here so if block gas limit exceeded, it'll panic and won't execute the msCache.Write(), so the tx msg side effects are not persisted.

[robert-zaremba]

makes sense. Thanks!

[amaury1093]

Merging!