Context chain ID can be empty #15269
Comments
tac0turtle
added
C:baseapp
T:Sprint
and removed
needs-triage
|
Hey @08d2 , can you share what commands are you using to replicate this? And what branch/tag are you on? I wasn't able to replicate this in main or release/v0.47.x. |
|
|
I was able to replicate now, thank you! I was resetting the whole state between tests. I'll take a look |
|
Sure thing. And just to reiterate, the problem here definitely isn't limited to just PrepareProposal and ChainID. All of the BaseApp states are probably partially invalid on startup, and anything called before the first block gets processed is probably affected. |
19 tasks
mergify bot
pushed a commit
that referenced
this issue
Mar 13, 2023
…in id in baseapp + fix context for verifying txs (#15303) ## Description ### Issue Some values (like chain ID) were being leaked from the previous block/initialization into PrepareProposal and ProcessProposal, these values are only available if: 1. The node has never been stopped since the genesis block (as these values are set on `InitChain`) 2. The node has already commited a block (as the previous header was being used for the new state of prepare and process proposal). So if a node is restarted, during the first prepare and process proposal these values won't be populated, and that will cause issues if they are being used. ### Solution Remove any previous header information from a previous block in the prepare and process proposal contexts, making things consistent at every height. - Added ChainID to baseapp - Use an empty header in Commit() with only the chain id set - Fix context for prepare and process proposal Closes: #15269 --- ### 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](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title - [ ] added `!` to the type prefix if API or client breaking change - [ ] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/main/CONTRIBUTING.md#pr-targeting)) - [ ] provided a link to the relevant issue or specification - [ ] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/main/docs/docs/building-modules) - [ ] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/main/CONTRIBUTING.md#testing) - [ ] added a changelog entry to `CHANGELOG.md` - [ ] included comments for [documenting Go code](https://blog.golang.org/godoc) - [ ] 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](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) 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)
mergify bot
pushed a commit
that referenced
this issue
Mar 13, 2023
…in id in baseapp + fix context for verifying txs (#15303) ## Description ### Issue Some values (like chain ID) were being leaked from the previous block/initialization into PrepareProposal and ProcessProposal, these values are only available if: 1. The node has never been stopped since the genesis block (as these values are set on `InitChain`) 2. The node has already commited a block (as the previous header was being used for the new state of prepare and process proposal). So if a node is restarted, during the first prepare and process proposal these values won't be populated, and that will cause issues if they are being used. ### Solution Remove any previous header information from a previous block in the prepare and process proposal contexts, making things consistent at every height. - Added ChainID to baseapp - Use an empty header in Commit() with only the chain id set - Fix context for prepare and process proposal Closes: #15269 --- ### 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](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title - [ ] added `!` to the type prefix if API or client breaking change - [ ] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/main/CONTRIBUTING.md#pr-targeting)) - [ ] provided a link to the relevant issue or specification - [ ] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/main/docs/docs/building-modules) - [ ] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/main/CONTRIBUTING.md#testing) - [ ] added a changelog entry to `CHANGELOG.md` - [ ] included comments for [documenting Go code](https://blog.golang.org/godoc) - [ ] 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](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) 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) (cherry picked from commit 6a03586) # Conflicts: # baseapp/abci_test.go # baseapp/baseapp.go # server/rollback.go # testutil/network/network.go
larry0x
pushed a commit
to larry0x/cosmos-sdk
that referenced
this issue
May 22, 2023
…in id in baseapp + fix context for verifying txs (cosmos#15303) ## Description ### Issue Some values (like chain ID) were being leaked from the previous block/initialization into PrepareProposal and ProcessProposal, these values are only available if: 1. The node has never been stopped since the genesis block (as these values are set on `InitChain`) 2. The node has already commited a block (as the previous header was being used for the new state of prepare and process proposal). So if a node is restarted, during the first prepare and process proposal these values won't be populated, and that will cause issues if they are being used. ### Solution Remove any previous header information from a previous block in the prepare and process proposal contexts, making things consistent at every height. - Added ChainID to baseapp - Use an empty header in Commit() with only the chain id set - Fix context for prepare and process proposal Closes: cosmos#15269 --- ### 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](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title - [ ] added `!` to the type prefix if API or client breaking change - [ ] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/main/CONTRIBUTING.md#pr-targeting)) - [ ] provided a link to the relevant issue or specification - [ ] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/main/docs/docs/building-modules) - [ ] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/main/CONTRIBUTING.md#testing) - [ ] added a changelog entry to `CHANGELOG.md` - [ ] included comments for [documenting Go code](https://blog.golang.org/godoc) - [ ] 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](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) 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)
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
BaseApp ABCI methods call application code, passing a context value taken from one of the BaseApp state fields, for example deliverState or prepareProposalState. The prepareProposal and processProposal state fields are initialized with an empty header, which means values like chain ID are empty. Those states get updated with each committed block, and once the node processes a block, the state fields are correctly set. But there is a period of time between node startup and first processed block, where application code can be called with a context value containing an empty chain ID. Specifically, the first call to PrepareProposal on node startup will receive a context where
ctx.ChainID() == "".There are most likely other calls in addition to PrepareProposal which can receive invalid contexts, and there are probably more fields in addition to ChainID which are invalid. These are just the specific things I've noticed.
The text was updated successfully, but these errors were encountered: