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

use local clock time as reference time for timeout timestamp if later than consensus state timestamp #568

Merged
merged 6 commits into from
Dec 2, 2021
Merged
17 changes: 16 additions & 1 deletion modules/apps/transfer/client/cli/tx.go
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,7 @@ package cli
import (
"fmt"
"strings"
"time"

"github.com/spf13/cobra"

Expand Down Expand Up @@ -89,7 +90,21 @@ to the counterparty channel. Any timeout set to 0 is disabled.`),
}

if timeoutTimestamp != 0 {
timeoutTimestamp = consensusState.GetTimestamp() + timeoutTimestamp
// use local clock time as reference time if it is later than the
// consensus state timestamp of the counter party chain, otherwise
// still use consensus state timestamp as reference
now := time.Now().UnixNano()
damiannolan marked this conversation as resolved.
Show resolved Hide resolved
consensusStateTimestamp := consensusState.GetTimestamp()
if now > 0 {
Copy link
Member

Choose a reason for hiding this comment

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

why would now be 0?

Copy link
Contributor Author

@crodriguezvega crodriguezvega Nov 29, 2021

Choose a reason for hiding this comment

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

I am being extremely defensive. It could potentially be 0 if the clock of the machine is (for who knows what reason) on Jan 1st 1970 12:00 AM. And it could be negative if the clock is set before that datetime.

Copy link
Contributor

Choose a reason for hiding this comment

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

Perhaps we can leave a comment explaining this? :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I will do that, yes.

Copy link
Contributor

@colin-axner colin-axner Nov 30, 2021

Choose a reason for hiding this comment

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

Maybe we should return an error if now is <= 0?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Initially I also thought of returning an error, but then I realized that it was a situation where we could still do our best effort to fulfill the request by using the consensus state timestamp.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, but this could cause problems in other areas of the codebase?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

All right, I can change it. No problem.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@colin-axner I pushed this change. Do you approve it the way it is now? If yes, then I will merge.

now := uint64(now)
if now > consensusStateTimestamp {
timeoutTimestamp = now + timeoutTimestamp

Choose a reason for hiding this comment

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

If the system clock is set far in the future, does this not create an effectively infinite timeout?

} else {
timeoutTimestamp = consensusStateTimestamp + timeoutTimestamp
}
} else {
timeoutTimestamp = consensusStateTimestamp + timeoutTimestamp
}
}
}

Expand Down