You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the handling of MsgTransfer, the code calls GetTimestampAtHeight() (here) when sending IBC packet to solo machine. GetTimestampAtHeight() is called with height returned by clientState.GetLatestHeight() (this returns the sequence stored in clientState for solo machine).
As the code increments the sequence at many places and does not store consensusState for new height (or sequence), GetClientConsensusState() fails (which is called inside GetTimestampAtHeight()). I've tried sending MsgUpdateClient before sending MsgTransfer but, even in the handling of MsgUpdateClient, the code increments the sequence of clientState (making it header.sequence + 1) and stores consensusState for header.sequence.
So, at all times, there seems to be is no way of getting consensusState for clientState.GetLatestHeight().
Thanks @devashishdx for testing the solo machine! GetTimestampAtHeight() is quite problematic for solo machines and is also blocking timeouts from working
We have a long term solution in mind for how to fix this effectively, but this requires a bit of work and due to the current resource constraints, I don't expect a fix until earliest sometime in the late fall
The only short term solution I can think of is hard coding a bypass check for solo machines. That is, if the client is a solo machine, skip the timeout check
The timeout is also a defensive check, but I think it is nice to have. Pinging @cwgoes
This check is defensive and can safely be skipped for solo machines. I suppose we could store past timestamps along with sequence numbers, but that adds extra storage cost for a defensive-only check - not desirable.
If we add a bypass for solo machines now, in the future we should change the abstraction to make it less awkward.
Summary of Bug
In the handling of
MsgTransfer
, the code callsGetTimestampAtHeight()
(here) when sending IBC packet to solo machine.GetTimestampAtHeight()
is called with height returned byclientState.GetLatestHeight()
(this returns the sequence stored inclientState
for solo machine).As the code increments the sequence at many places and does not store
consensusState
for new height (or sequence),GetClientConsensusState()
fails (which is called insideGetTimestampAtHeight()
). I've tried sendingMsgUpdateClient
before sendingMsgTransfer
but, even in the handling ofMsgUpdateClient
, the code increments the sequence ofclientState
(making itheader.sequence + 1
) and storesconsensusState
forheader.sequence
.So, at all times, there seems to be is no way of getting
consensusState
forclientState.GetLatestHeight()
.Version
master
Steps to Reproduce
MsgUpdateClient
and thenMsgTransfer
.For Admin Use
The text was updated successfully, but these errors were encountered: