Skip to content

Fix Begin/EndBlock stuck at infinite loop in contracts#457

Merged
codchen merged 8 commits intomasterfrom
tony-chen-fix-infinite-loop
Dec 20, 2022
Merged

Fix Begin/EndBlock stuck at infinite loop in contracts#457
codchen merged 8 commits intomasterfrom
tony-chen-fix-infinite-loop

Conversation

@codchen
Copy link
Collaborator

@codchen codchen commented Dec 19, 2022

Describe your changes and provide context

The wasm module would allow contracts to run forever if ctx.GasMeter() doesn't have a limit. So instead of using an infinite meter as the temporary meter (which was originally added to prevent race conditions between concurrent calls), we will use one that inherits the limit depending on whether it's called within BeginBlock or EndBlock (inferred from ctx.GasMeter().Limit().

Testing performed to validate your change

Tested on local chain with contract that has infinite loop in hooks

@codchen codchen requested a review from BrandonWeng December 19, 2022 04:06
defer metrics.MeasureSudoExecutionDuration(time.Now(), msgType)
// set up a tmp context to prevent race condition in reading gas consumed
tmpCtx := sdkCtx.WithGasMeter(sdk.NewInfiniteGasMeter())
tmpCtx := sdkCtx.WithGasMeter(sdk.NewGasMeter(sdkCtx.GasMeter().Limit()))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where is this gas limit determined for begin / end block?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't account for the already spent gas though, right? because lets say gas limit is 1000, but the beginblock already spent 250, and the wasm contract needs 800. Then with this current PR, it would allow a total consumption of 1050 gas, right? or is that fine since we're only looking to mitigate the infinite gas issue?

Copy link
Collaborator Author

@codchen codchen Dec 19, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that's intentional. We don't want to take into account already spent gas because otherwise it may cause non-determinism - contract A may be processed and consume most gas in val 1 and contract B would fail because it only has little gas remaining whereas it could be opposite in val 2.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So IUCC in some cases (example Uday listed above) may perform more computation than the original gas limit but it will still fail later when we check the gas consumed?

	gasConsumed := tmpCtx.GasMeter().GasConsumed()
	if gasConsumed > 0 {
		sdkCtx.GasMeter().ConsumeGas(gasConsumed, "sudo")
	}

If so, it might be useful to add a comment here for future reference.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it would fail later because of greater than expected gas consumption, because the gas being consumed by contracts is on a new meter, so doesn't actually affect the original gas meter. I was just wondering whether that was ok considering that gas is generally tied to compute cost but this seems fine.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah the gas limit is more like "no individual call can exceed it", but a soft limit overall. I'll add a comment for this

@github-actions
Copy link

Code Coverage

Package Line Rate Complexity Health
github.com/sei-protocol/sei-chain/aclmapping/bank 100% 0
github.com/sei-protocol/sei-chain/aclmapping/dex 97% 0
github.com/sei-protocol/sei-chain/aclmapping/oracle 100% 0
github.com/sei-protocol/sei-chain/aclmapping/staking 82% 0
github.com/sei-protocol/sei-chain/aclmapping/tokenfactory 96% 0
github.com/sei-protocol/sei-chain/aclmapping/utils 0% 0
github.com/sei-protocol/sei-chain/aclmapping/wasm 83% 0
github.com/sei-protocol/sei-chain/app 52% 0
github.com/sei-protocol/sei-chain/app/antedecorators 89% 0
github.com/sei-protocol/sei-chain/oracle/price-feeder/config 85% 0
github.com/sei-protocol/sei-chain/oracle/price-feeder/oracle 73% 0
github.com/sei-protocol/sei-chain/oracle/price-feeder/oracle/provider 48% 0
github.com/sei-protocol/sei-chain/oracle/price-feeder/router/v1 45% 0
github.com/sei-protocol/sei-chain/store/whitelist/cachemulti 100% 0
github.com/sei-protocol/sei-chain/store/whitelist/kv 100% 0
github.com/sei-protocol/sei-chain/store/whitelist/multi 100% 0
github.com/sei-protocol/sei-chain/utils 46% 0
github.com/sei-protocol/sei-chain/utils/datastructures 90% 0
github.com/sei-protocol/sei-chain/x/dex 59% 0
github.com/sei-protocol/sei-chain/x/dex/cache 86% 0
github.com/sei-protocol/sei-chain/x/dex/client/cli/query 23% 0
github.com/sei-protocol/sei-chain/x/dex/contract 52% 0
github.com/sei-protocol/sei-chain/x/dex/exchange 89% 0
github.com/sei-protocol/sei-chain/x/dex/keeper 61% 0
github.com/sei-protocol/sei-chain/x/dex/keeper/abci 30% 0
github.com/sei-protocol/sei-chain/x/dex/keeper/msgserver 78% 0
github.com/sei-protocol/sei-chain/x/dex/keeper/query 82% 0
github.com/sei-protocol/sei-chain/x/dex/migrations 85% 0
github.com/sei-protocol/sei-chain/x/dex/types 1% 0
github.com/sei-protocol/sei-chain/x/dex/types/utils 100% 0
github.com/sei-protocol/sei-chain/x/dex/types/wasm 83% 0
github.com/sei-protocol/sei-chain/x/epoch 11% 0
github.com/sei-protocol/sei-chain/x/epoch/keeper 66% 0
github.com/sei-protocol/sei-chain/x/epoch/types 2% 0
github.com/sei-protocol/sei-chain/x/mint 0% 0
github.com/sei-protocol/sei-chain/x/mint/keeper 75% 0
github.com/sei-protocol/sei-chain/x/mint/simulation 95% 0
github.com/sei-protocol/sei-chain/x/mint/types 2% 0
github.com/sei-protocol/sei-chain/x/nitro/client/cli 45% 0
github.com/sei-protocol/sei-chain/x/nitro/keeper 80% 0
github.com/sei-protocol/sei-chain/x/nitro/replay 63% 0
github.com/sei-protocol/sei-chain/x/oracle 63% 0
github.com/sei-protocol/sei-chain/x/oracle/keeper 82% 0
github.com/sei-protocol/sei-chain/x/oracle/simulation 18% 0
github.com/sei-protocol/sei-chain/x/oracle/types 3% 0
github.com/sei-protocol/sei-chain/x/tokenfactory/keeper 85% 0
github.com/sei-protocol/sei-chain/x/tokenfactory/types 2% 0
Summary 15% (4913 / 33806) 0

@codchen codchen merged commit e3373eb into master Dec 20, 2022
masih pushed a commit that referenced this pull request Sep 29, 2025
## Describe your changes and provide context
When we create tokens using token factory, denoms are created in the
`factory/{owner_walltet_id}/{denom}` format
E.g. `factory/sei1gxskuzvhr4s8sdm2rpruaf7yx2dnmjn0zfdu9q/NEWCOIN`

When querying metadata via
`/cosmos/bank/v1beta1/denoms_metadata/{denom}` endpoint for such a denom
we are getting error like
```
{
    "code": 12,
    "message": "Not Implemented",
    "details": []
}
```
This happens, because routing logic splits the denom uri param into 3
components rather then one and hence tries to router request to a
non-existing handler. Url encoding does not help either as it still
results in same issue. We would like to add additional endpoint to
handle token factory created metadata retrieval, and move denom for the
endpoint from uri param to query param.

so then for token factory created tokens the query would be 

`/cosmos/bank/v1beta1/token_factory/denoms_metadata?denom=factory/{owner_walltet_id}/{denom}`

## Testing performed to validate your change
Note: some demom tests were disables, and I have enabled them.

- Functional testing on local node with updated source
- unit/integration tests
masih pushed a commit that referenced this pull request Sep 30, 2025
## Describe your changes and provide context
When we create tokens using token factory, denoms are created in the
`factory/{owner_walltet_id}/{denom}` format
E.g. `factory/sei1gxskuzvhr4s8sdm2rpruaf7yx2dnmjn0zfdu9q/NEWCOIN`

When querying metadata via
`/cosmos/bank/v1beta1/denoms_metadata/{denom}` endpoint for such a denom
we are getting error like
```
{
    "code": 12,
    "message": "Not Implemented",
    "details": []
}
```
This happens, because routing logic splits the denom uri param into 3
components rather then one and hence tries to router request to a
non-existing handler. Url encoding does not help either as it still
results in same issue. We would like to add additional endpoint to
handle token factory created metadata retrieval, and move denom for the
endpoint from uri param to query param.

so then for token factory created tokens the query would be 

`/cosmos/bank/v1beta1/token_factory/denoms_metadata?denom=factory/{owner_walltet_id}/{denom}`

## Testing performed to validate your change
Note: some demom tests were disables, and I have enabled them.

- Functional testing on local node with updated source
- unit/integration tests
@masih masih deleted the tony-chen-fix-infinite-loop branch October 31, 2025 15:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants