Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Impossible to create IBC channels after on-chain upgrade #9800

Closed
4 tasks
Tracked by #9801
RiccardoM opened this issue Jul 28, 2021 · 26 comments · Fixed by #9835 or #9836
Closed
4 tasks
Tracked by #9801

Impossible to create IBC channels after on-chain upgrade #9800

RiccardoM opened this issue Jul 28, 2021 · 26 comments · Fixed by #9835 or #9836
Assignees
Labels
Milestone

Comments

@RiccardoM
Copy link
Contributor

Summary of Bug

After running an on-chain upgrade, it is impossible to create new IBC channels.

Version

v0.42.7

Steps to Reproduce

  1. Start a localnet and create some IBC channels with other chains.
  2. Perform a simple on-chain upgrade (no need to have consensus-breaking changes)
  3. Try to create a new IBC channel.

The following error will be displayed:

failed to execute message; message index: 0: channel handshake open init failed: caller does not own port capability for port ID <Port ID>: invalid port

This happens with both custom modules and the transfer module.

The error started showing up only after the upgrade, while before the upgrade itself it was possible to create correct channels that worked without any issue.

The upgrade has been tested on our testnet and did not have any change apart from the IBC version checking being deleted since we do not need it.


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
@yihuang
Copy link
Collaborator

yihuang commented Jul 28, 2021

Is the "simple on-chain upgrade” is an export upgrade, or upgrade module upgrade?

@RiccardoM
Copy link
Contributor Author

Is the "simple on-chain upgrade” is an export upgrade, or upgrade module upgrade?

It used the x/upgrade module without performing any consensus-breaking changes. It only removed the IBC version checking from our custom module (as you can see here)

@AdityaSripal
Copy link
Member

Do you have the following lines in your app.go?

https://github.com/cosmos/gaia/blob/main/app/app.go#L455

@RiccardoM
Copy link
Contributor Author

RiccardoM commented Jul 28, 2021

Do you have the following lines in your app.go?

https://github.com/cosmos/gaia/blob/main/app/app.go#L455

Of course. You can see the post-upgrade files here

@AdityaSripal
Copy link
Member

Hmm that should have reinitialized the in-memory capabilities. I will test this issue, thanks for the writeup

@AdityaSripal AdityaSripal self-assigned this Jul 28, 2021
@amaury1093 amaury1093 added this to the v0.42.X milestone Jul 28, 2021
@AdityaSripal
Copy link
Member

Hi @RiccardoM ,

@colin-axner just tried to reproduce your issue and did not run into any issues.

  1. We used gaiad-manager to set up two chains on v0.42.7.
  2. Setup a channel before upgrade and sent packet
  3. Make regular simple upgrade using upgrade module
  4. Setup a new channel and sent packet

There was no errors with this workflow. Could you provide more information on what you did beyond the steps above?

@RiccardoM
Copy link
Contributor Author

RiccardoM commented Jul 28, 2021

@AdityaSripal Aside from those operations, we did nothing. We had a running chain with different channels opened, we performed the upgrade and I tried to create a new channel after the upgrade. If I query the previously created channels I can see them being there, but if I try to create a new one I end up with the above mentioned error.

For a better understanding, we had a chain running with the following details:

and we upgraded to use Desmos v0.17.4.

The upgrade was successful and most of the validators used cosmovisor

@RiccardoM
Copy link
Contributor Author

@AdityaSripal @colin-axner If you have any idea how I might debug this (maybe something particular to look at?) let me know please cause this is currently blocking our testnet from having any integration with other chains over IBC

@AdityaSripal
Copy link
Member

  1. Could you double check that you are bound to the port that you are trying to create a channel with?
  2. If you have access to node logs, could you modify the binary to print out some info that might be useful?

If so, could you print the following info:

If you could then show the outputs here that would be great. Ideally we want to see that on a node restart these are called and correctly filled in.

@AdityaSripal
Copy link
Member

This was already tested before IBC launch and we haven't changed that code. Don't know exactly what could be the issue but it would be useful to at least rule out some things

@AdityaSripal
Copy link
Member

Also are you able to send/receive packets on an already existing channel?

@AdityaSripal
Copy link
Member

Also have you been using statesync in any way?

@RiccardoM
Copy link
Contributor Author

RiccardoM commented Jul 28, 2021

Also are you able to send/receive packets on an already existing channel?

I can't. I've tried using desmos tx ibc-transfer transfer with an already existing channel and I I can't. I get the following error:

Error: rpc error: code = InvalidArgument desc = failed to execute message; message index: 0: caller does not own capability for channel, port ID (transfer) channel ID (channel-1): channel capability not found: invalid request

This is the channel details

- channel_id: channel-1
  connection_hops:
  - connection-5
  counterparty:
    channel_id: channel-2
    port_id: transfer
  ordering: ORDER_UNORDERED
  port_id: transfer
  state: STATE_OPEN
  version: ics20-1

Also have you been using statesync in any way?

No state sync has been used for this node. It has been synced from genesis and is currently using pruning: "nothing".

@RiccardoM
Copy link
Contributor Author

If you could then show the outputs here that would be great. Ideally we want to see that on a node restart these are called and correctly filled in.

I've added the logs inside this commit. Here are the results:

3:05PM ERR InitializeCapability - Printing the cap owners
3:05PM ERR capability cap owner fwd_key=ibc/fwd/0xc000be6688 rev_key=ibc/rev/ports/transfer
3:05PM ERR capability cap owner fwd_key=transfer/fwd/0xc000be6688 rev_key=transfer/rev/ports/transfer
3:05PM ERR InitializeCapability - Printing the cap owners
3:05PM ERR capability cap owner fwd_key=ibc/fwd/0xc000be6a80 rev_key=ibc/rev/capabilities/ports/transfer/channels/channel-0
3:05PM ERR capability cap owner fwd_key=transfer/fwd/0xc000be6a80 rev_key=transfer/rev/capabilities/ports/transfer/channels/channel-0
3:05PM ERR InitializeCapability - Printing the cap owners
3:05PM ERR capability cap owner fwd_key=ibc/fwd/0xc000be6e50 rev_key=ibc/rev/capabilities/ports/transfer/channels/channel-1
3:05PM ERR capability cap owner fwd_key=transfer/fwd/0xc000be6e50 rev_key=transfer/rev/capabilities/ports/transfer/channels/channel-1
3:05PM ERR InitializeCapability - Printing the cap owners
3:05PM ERR capability cap owner fwd_key=ibc/fwd/0xc000be7200 rev_key=ibc/rev/ports/ibc-profiles
3:05PM ERR capability cap owner fwd_key=profiles/fwd/0xc000be7200 rev_key=profiles/rev/ports/ibc-profiles
3:05PM ERR InitializeCapability - Printing the cap owners
3:05PM ERR capability cap owner fwd_key=ibc/fwd/0xc000be75b0 rev_key=ibc/rev/capabilities/ports/ibc-profiles/channels/channel-2
3:05PM ERR capability cap owner fwd_key=profiles/fwd/0xc000be75b0 rev_key=profiles/rev/capabilities/ports/ibc-profiles/channels/channel-2
3:05PM ERR InitializeCapability - Printing the cap owners
3:05PM ERR capability cap owner fwd_key=ibc/fwd/0xc000be79a0 rev_key=ibc/rev/capabilities/ports/ibc-profiles/channels/channel-3
3:05PM ERR capability cap owner fwd_key=profiles/fwd/0xc000be79a0 rev_key=profiles/rev/capabilities/ports/ibc-profiles/channels/channel-3

Looks like GetCapability and LookupModules are not called. Should they be called at start or not?

@robert-zaremba
Copy link
Collaborator

robert-zaremba commented Jul 28, 2021

Does this impact the 0.43 release as well? Is anyone working on a PR?

@AdityaSripal
Copy link
Member

Looks like GetCapability and LookupModules are not called. Should they be called at start or not?

No they shouldn't but they should be called when you try to open a channel. The logs I see seem to show that we are correctly filling in memory on restart.

Could you also print out what you see in the logs once you try opening a channel?

@RiccardoM
Copy link
Contributor Author

RiccardoM commented Jul 29, 2021

@AdityaSripal Here are the logs when I try creating a channel

10:12AM ERR GetCapability - Scoped keeper is not initialized. Initializing...
10:12AM ERR InitializeCapability - Printing the cap owners
10:12AM ERR capability cap owner fwd_key=ibc/fwd/0xc007976688 rev_key=ibc/rev/ports/transfer
10:12AM ERR capability cap owner fwd_key=transfer/fwd/0xc007976688 rev_key=transfer/rev/ports/transfer
10:12AM ERR InitializeCapability - Printing the cap owners
10:12AM ERR capability cap owner fwd_key=ibc/fwd/0xc0079768c0 rev_key=ibc/rev/capabilities/ports/transfer/channels/channel-0
10:12AM ERR capability cap owner fwd_key=transfer/fwd/0xc0079768c0 rev_key=transfer/rev/capabilities/ports/transfer/channels/channel-0
10:12AM ERR InitializeCapability - Printing the cap owners
10:12AM ERR capability cap owner fwd_key=ibc/fwd/0xc007976ad0 rev_key=ibc/rev/capabilities/ports/transfer/channels/channel-1
10:12AM ERR capability cap owner fwd_key=transfer/fwd/0xc007976ad0 rev_key=transfer/rev/capabilities/ports/transfer/channels/channel-1
10:12AM ERR InitializeCapability - Printing the cap owners
10:12AM ERR capability cap owner fwd_key=ibc/fwd/0xc007976cf0 rev_key=ibc/rev/ports/ibc-profiles
10:12AM ERR capability cap owner fwd_key=profiles/fwd/0xc007976cf0 rev_key=profiles/rev/ports/ibc-profiles
10:12AM ERR InitializeCapability - Printing the cap owners
10:12AM ERR capability cap owner fwd_key=ibc/fwd/0xc007976f00 rev_key=ibc/rev/capabilities/ports/ibc-profiles/channels/channel-2
10:12AM ERR capability cap owner fwd_key=profiles/fwd/0xc007976f00 rev_key=profiles/rev/capabilities/ports/ibc-profiles/channels/channel-2
10:12AM ERR InitializeCapability - Printing the cap owners
10:12AM ERR capability cap owner fwd_key=ibc/fwd/0xc007977110 rev_key=ibc/rev/capabilities/ports/ibc-profiles/channels/channel-3
10:12AM ERR capability cap owner fwd_key=profiles/fwd/0xc007977110 rev_key=profiles/rev/capabilities/ports/ibc-profiles/channels/channel-3
10:12AM ERR LookupModules - Printing the cap owners...
10:12AM ERR cap owner cap_owner={"module":"ibc","name":"ports/ibc-profiles"} index=0
10:12AM ERR cap owner cap_owner={"module":"profiles","name":"ports/ibc-profiles"} index=1

Command used:

ibc-setup channel -v \
  --src-connection connection-13 \
  --dest-connection connection-210 \
  --src-port ibc-profiles \
  --dest-port oracle \
  --version bandchain-1

It appears that the node in which I executed the command (running the new binary with logs enabled) successfully created it. But from its logs we can see that the majority of the nodes didn't:

10:12AM ERR prevote step: ProposalBlock is invalid err="wrong Block.Header.AppHash.  Expected D01D21E49443B465D39C1D3957FEF1D5395467F865A3C2AD995D193F8A592776, got 3B1690562854EE2AA4C4D9A3FE703DF671BB228ED8444B478CD8022D2ED11D12" height=1281061 module=consensus round=0
10:12AM ERR CONSENSUS FAILURE!!! err="precommit step; +2/3 prevoted for an invalid block: wrong Block.Header.AppHash.  Expected D01D21E49443B465D39C1D3957FEF1D5395467F865A3C2AD995D193F8A592776, got 3B1690562854EE2AA4C4D9A3FE703DF671BB228ED8444B478CD8022D2ED11D12" module=consensus stack="goroutine 369 [running]:\nruntime/debug.Stack(0xc0028ab370, 0x1aa5000, 0xc00bc48560)\n\truntime/debug/stack.go:24 +0x9f\ngh.neting.cc/tendermint/tendermint/consensus.(*State).receiveRoutine.func2(0xc000f84e00, 0x1ffc9a0)\n\tgh.neting.cc/tendermint/tendermint@v0.34.11/consensus/state.go:726 +0x5b\npanic(0x1aa5000, 0xc00bc48560)\n\truntime/panic.go:965 +0x1b9\ngh.neting.cc/tendermint/tendermint/consensus.(*State).enterPrecommit(0xc000f84e00, 0x138c25, 0x0)\n\tgh.neting.cc/tendermint/tendermint@v0.34.11/consensus/state.go:1390 +0x1c4c\ngh.neting.cc/tendermint/tendermint/consensus.(*State).addVote(0xc000f84e00, 0xc00d644aa0, 0xc00cee8b10, 0x28, 0x1ffed40, 0xc0028abc08, 0x10831b9)\n\tgh.neting.cc/tendermint/tendermint@v0.34.11/consensus/state.go:2104 +0x131e\ngh.neting.cc/tendermint/tendermint/consensus.(*State).tryAddVote(0xc000f84e00, 0xc00d644aa0, 0xc00cee8b10, 0x28, 0xc00b585900, 0xc00b589200, 0xc038bda55b8512a8)\n\tgh.neting.cc/tendermint/tendermint@v0.34.11/consensus/state.go:1930 +0x56\ngh.neting.cc/tendermint/tendermint/consensus.(*State).handleMsg(0xc000f84e00, 0x21eaee0, 0xc00b5fe2a0, 0xc00cee8b10, 0x28)\n\tgh.neting.cc/tendermint/tendermint@v0.34.11/consensus/state.go:838 +0x8cd\ngh.neting.cc/tendermint/tendermint/consensus.(*State).receiveRoutine(0xc000f84e00, 0x0)\n\tgh.neting.cc/tendermint/tendermint@v0.34.11/consensus/state.go:762 +0x3f2\ncreated by github.com/tendermint/tendermint/consensus.(*State).OnStart\n\tgh.neting.cc/tendermint/tendermint@v0.34.11/consensus/state.go:378 +0x8c5\n"

@colin-axner
Copy link
Contributor

@RiccardoM Does this issue only arise when interacting with ibc-profiles ports? I tried to reproduce the error using transfer channels, using the desmos binaries above and doing the exact same upgrade. The only thing I did differently was use a fresh genesis, but that shouldn't have any affect. I did not test opening channels for ibc-profiles. Can you confirm this issue exists for transfer channels as well?

@RiccardoM
Copy link
Contributor Author

RiccardoM commented Jul 29, 2021

@RiccardoM Does this issue only arise when interacting with ibc-profiles ports? I tried to reproduce the error using transfer channels, using the desmos binaries above and doing the exact same upgrade. The only thing I did differently was use a fresh genesis, but that shouldn't have any affect. I did not test opening channels for ibc-profiles. Can you confirm this issue exists for transfer channels as well?

Yes, the channel handshake open init failed error arose also using the transfer port, always inside the same node that returns this error with the ibc-profiles port too.

I can also confirm that opening channels for both ibc-profiles and transfer ports worked flawlessly before the upgrade.

@colin-axner
Copy link
Contributor

Interesting so, the network itself is capable of opening new channels, but just this node is having issues?

@RiccardoM
Copy link
Contributor Author

RiccardoM commented Jul 29, 2021

Interesting so, the network itself is capable of opening new channels, but just this node is having issues?

No, the opposite. The network is not able, but this node is now (after replacing the binary with the logger one) apparently.

@RiccardoM
Copy link
Contributor Author

Just noticed: one difference is that I've now started the desmos process using the binary directly, while the other nodes are all managed by cosmovisor

@robert-zaremba
Copy link
Collaborator

robert-zaremba commented Jul 29, 2021

Just noticed: one difference is that I've now started the desmos process using the binary directly, while the other nodes are all managed by cosmovisor

Have you observed any error from cosmovisor?

@AdityaSripal
Copy link
Member

Have you observed any error from cosmovisor?

No we did the test with cosmovisor both without upgrading and with upgrading and ran into no issues. Doesn't seem like cosmovisor is related to issue at all.

@AdityaSripal
Copy link
Member

Thanks to @colin-axner for finding the potential bug, and to @RiccardoM for helping to debug today.

We think we understand what the problem is. As mentioned in the original statesync fix #9392 , we introduced a global initialized variable to the capability module and repopulated the in-memory fields on the first GetCapability. This will work if the first transaction that calls GetCapability is successful.

However, if the first tx that calls GetCapability is unsuccessful then the transaction state changes will get reverted. This means that the changes to the memstores (fwd and reverse mappings) get reverted. But the writes to the internal go map, do not get reverted as they are not part of the context.

Thus, in this case we reach an inconsistent state in the capability module and worse still, the global initialized variable is set to true thus preventing the memory store from being populated correctly on the next transaction.

This would explain the behaviour we are seeing. It explains why when debugging with @RiccardoM today we could not reproduce because the first tx we tried after restart was successful.

It also explains the issue with nodes on other networks where the first tx passes the capability checks and fails later down the line, triggering the problem described above and then subsequent tx's fail on the capability check.

It also explains the non-deterministic behaviour of the problem since it will only arise for nodes that have statesynced (or restarted) to a height right before a failing channel tx.

@AdityaSripal
Copy link
Member

Given the above understanding this is the next steps for the IBC team.

  1. Verify that this is actually the issue by reproducing it (Send an intentionally failing channel tx after an upgrade/restart, and then try a channel tx)
  2. Write up a very defensive backwards compatible fix. This will ensure at GetCapability that the memory stores are completely in-sync with persistent store before proceeding. If not, it will re-populate the memory store and capability map with the correct values. Merge this into v0.42 line
  3. Write a clean fix to get into v0.43. This will be a breaking change that is hopefully cleaner than the backwards compatible one

@mergify mergify bot closed this as completed in #9836 Aug 3, 2021
mergify bot pushed a commit that referenced this issue Aug 3, 2021
<!--
The default pull request template is for types feat, fix, or refactor.
For other templates, add one of the following parameters to the url:
- template=docs.md
- template=other.md
-->

## Description

Closes: #9800

The following is a breaking fix to #9800. In the non-breaking fix, the initialization logic was moved out of `InitializeAndSeal` but the API was preserved. I've now removed `InitializeAndSeal` and replaced it with just the `Seal` function, which may be called much more cleanly in `app.go`

---

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

- [x] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title
- [x] added `!` to the type prefix if API or client breaking change
- [x] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#pr-targeting))
- [x] provided a link to the relevant issue or specification
- [x] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/master/docs/building-modules)
- [x] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#testing)
- [x] added a changelog entry to `CHANGELOG.md`
- [x] included comments for [documenting Go code](https://blog.golang.org/godoc)
- [x] updated the relevant documentation or specification
- [x] 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 Aug 3, 2021
<!--
The default pull request template is for types feat, fix, or refactor.
For other templates, add one of the following parameters to the url:
- template=docs.md
- template=other.md
-->

## Description

Closes: #9800

The following is a breaking fix to #9800. In the non-breaking fix, the initialization logic was moved out of `InitializeAndSeal` but the API was preserved. I've now removed `InitializeAndSeal` and replaced it with just the `Seal` function, which may be called much more cleanly in `app.go`

---

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

- [x] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title
- [x] added `!` to the type prefix if API or client breaking change
- [x] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#pr-targeting))
- [x] provided a link to the relevant issue or specification
- [x] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/master/docs/building-modules)
- [x] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#testing)
- [x] added a changelog entry to `CHANGELOG.md`
- [x] included comments for [documenting Go code](https://blog.golang.org/godoc)
- [x] updated the relevant documentation or specification
- [x] 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 7f316ad)

# Conflicts:
#	CHANGELOG.md
robert-zaremba added a commit that referenced this issue Aug 4, 2021
…#9841)

* fix!: Capability Issue on Restart, Backport to v0.43 (#9836)

<!--
The default pull request template is for types feat, fix, or refactor.
For other templates, add one of the following parameters to the url:
- template=docs.md
- template=other.md
-->

## Description

Closes: #9800

The following is a breaking fix to #9800. In the non-breaking fix, the initialization logic was moved out of `InitializeAndSeal` but the API was preserved. I've now removed `InitializeAndSeal` and replaced it with just the `Seal` function, which may be called much more cleanly in `app.go`

---

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

- [x] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title
- [x] added `!` to the type prefix if API or client breaking change
- [x] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#pr-targeting))
- [x] provided a link to the relevant issue or specification
- [x] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/master/docs/building-modules)
- [x] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#testing)
- [x] added a changelog entry to `CHANGELOG.md`
- [x] included comments for [documenting Go code](https://blog.golang.org/godoc)
- [x] updated the relevant documentation or specification
- [x] 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 7f316ad)

# Conflicts:
#	CHANGELOG.md

* solve conflicts

Co-authored-by: Aditya <adityasripal@gmail.com>
Co-authored-by: Robert Zaremba <robert@zaremba.ch>
evan-forbes pushed a commit to evan-forbes/cosmos-sdk that referenced this issue Oct 12, 2021
…#9836) (cosmos#9841)

* fix!: Capability Issue on Restart, Backport to v0.43 (cosmos#9836)

<!--
The default pull request template is for types feat, fix, or refactor.
For other templates, add one of the following parameters to the url:
- template=docs.md
- template=other.md
-->

## Description

Closes: cosmos#9800

The following is a breaking fix to cosmos#9800. In the non-breaking fix, the initialization logic was moved out of `InitializeAndSeal` but the API was preserved. I've now removed `InitializeAndSeal` and replaced it with just the `Seal` function, which may be called much more cleanly in `app.go`

---

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

- [x] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title
- [x] added `!` to the type prefix if API or client breaking change
- [x] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#pr-targeting))
- [x] provided a link to the relevant issue or specification
- [x] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/master/docs/building-modules)
- [x] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#testing)
- [x] added a changelog entry to `CHANGELOG.md`
- [x] included comments for [documenting Go code](https://blog.golang.org/godoc)
- [x] updated the relevant documentation or specification
- [x] 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 7f316ad)

# Conflicts:
#	CHANGELOG.md

* solve conflicts

Co-authored-by: Aditya <adityasripal@gmail.com>
Co-authored-by: Robert Zaremba <robert@zaremba.ch>
evan-forbes pushed a commit to evan-forbes/cosmos-sdk that referenced this issue Nov 1, 2021
…#9836) (cosmos#9841)

* fix!: Capability Issue on Restart, Backport to v0.43 (cosmos#9836)

<!--
The default pull request template is for types feat, fix, or refactor.
For other templates, add one of the following parameters to the url:
- template=docs.md
- template=other.md
-->

## Description

Closes: cosmos#9800

The following is a breaking fix to cosmos#9800. In the non-breaking fix, the initialization logic was moved out of `InitializeAndSeal` but the API was preserved. I've now removed `InitializeAndSeal` and replaced it with just the `Seal` function, which may be called much more cleanly in `app.go`

---

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

- [x] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title
- [x] added `!` to the type prefix if API or client breaking change
- [x] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#pr-targeting))
- [x] provided a link to the relevant issue or specification
- [x] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/master/docs/building-modules)
- [x] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#testing)
- [x] added a changelog entry to `CHANGELOG.md`
- [x] included comments for [documenting Go code](https://blog.golang.org/godoc)
- [x] updated the relevant documentation or specification
- [x] 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 7f316ad)

# Conflicts:
#	CHANGELOG.md

* solve conflicts

Co-authored-by: Aditya <adityasripal@gmail.com>
Co-authored-by: Robert Zaremba <robert@zaremba.ch>
larry0x pushed a commit to larry0x/cosmos-sdk that referenced this issue May 22, 2023
<!--
The default pull request template is for types feat, fix, or refactor.
For other templates, add one of the following parameters to the url:
- template=docs.md
- template=other.md
-->

## Description

Closes: cosmos#9800

The following is a breaking fix to cosmos#9800. In the non-breaking fix, the initialization logic was moved out of `InitializeAndSeal` but the API was preserved. I've now removed `InitializeAndSeal` and replaced it with just the `Seal` function, which may be called much more cleanly in `app.go`

---

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

- [x] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title
- [x] added `!` to the type prefix if API or client breaking change
- [x] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#pr-targeting))
- [x] provided a link to the relevant issue or specification
- [x] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/master/docs/building-modules)
- [x] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#testing)
- [x] added a changelog entry to `CHANGELOG.md`
- [x] included comments for [documenting Go code](https://blog.golang.org/godoc)
- [x] updated the relevant documentation or specification
- [x] 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)
JeancarloBarrios pushed a commit to agoric-labs/cosmos-sdk that referenced this issue Sep 28, 2024
…#9836) (cosmos#9841)

* fix!: Capability Issue on Restart, Backport to v0.43 (cosmos#9836)

<!--
The default pull request template is for types feat, fix, or refactor.
For other templates, add one of the following parameters to the url:
- template=docs.md
- template=other.md
-->

## Description

Closes: cosmos#9800

The following is a breaking fix to cosmos#9800. In the non-breaking fix, the initialization logic was moved out of `InitializeAndSeal` but the API was preserved. I've now removed `InitializeAndSeal` and replaced it with just the `Seal` function, which may be called much more cleanly in `app.go`

---

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

- [x] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title
- [x] added `!` to the type prefix if API or client breaking change
- [x] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#pr-targeting))
- [x] provided a link to the relevant issue or specification
- [x] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/master/docs/building-modules)
- [x] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#testing)
- [x] added a changelog entry to `CHANGELOG.md`
- [x] included comments for [documenting Go code](https://blog.golang.org/godoc)
- [x] updated the relevant documentation or specification
- [x] 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 7f316ad)

# Conflicts:
#	CHANGELOG.md

* solve conflicts

Co-authored-by: Aditya <adityasripal@gmail.com>
Co-authored-by: Robert Zaremba <robert@zaremba.ch>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment