lyqingye

> Note that there is a simple fix for this we included in PR #2167. The problem is also discussed here: https://github.com/informalsystems/ibc-rs/issues/1971#issuecomment-1117135293 > > > > The fix is: >...

> > Note that there is a simple fix for this we included in PR #2167. The problem is also discussed here: https://github.com/informalsystems/ibc-rs/issues/1971#issuecomment-1117135293 > > > > > > >...

> I probably understand what you mean. The first batch has been submitted to the mem-pool. Subsequent batches can ignore the exception and submit it directly to the mem-pool. when...

> > I probably understand what you mean. The first batch has been submitted to the mem-pool. Subsequent batches can ignore the exception and submit it directly to the mem-pool....

> > that is my [solution](https://github.com/falcons-x/ibc-rs/commit/8e3d2aef433cb2b64ed40ac837c8f34ef420937b) > > Current design is to fill a Tx with messages until either `max_msg_num` or `max_tx_size` are reached, whichever occurs first. The logic in...

> Hi @lyqingye, we plan to test the connection delay feature more extensively as part of #1836. This issue might be related to #1772 (as Adi noted), but can you...

> > delay_period = 0ns, so i think this issue not related to #1772 > > agreed. What versions of ibc-go/sdk are the chains you tested with? ibc-go: v3.0.0

I guess it's because the ConsensusState contains the app hash (merkle root) of the previous block, so PacketProof Height + 1 = ConsensusState Height