fix: use UTC time for packet timeout error

[GAtom22]

Description

Problem

When using a timeout timestamp, the packet timeout error message will return a different time depending on the node's timezone configuration.

For example, for the same packet, we'll have:

In a node with CET timezone:

receiving chain block timestamp >= packet timeout timestamp (2023-08-09 14:12:07.556572046 +0200 CEST >= 1970-01-01 01:00:00.00001 +0100 CET): packet timeout

In a node with UTC timezone:

receiving chain block timestamp >= packet timeout timestamp (2023-08-09 12:12:07.556572046 +0000 UTC >= 1970-01-01 00:00:00.00001 +0000 UTC): packet timeout

Solution

Unify this using UTC timezone independently of server timezone configuration

closes: #XXXX

Commit Message / Changelog Entry

type: commit message

see the guidelines for commit messages. (view raw markdown for examples)

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Targeted PR against correct branch (see CONTRIBUTING.md).
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• Code follows the module structure standards and Go style guide.
• Wrote unit and integration tests.
• Updated relevant documentation (docs/) or specification (x/<module>/spec/).
• Added relevant godoc comments.
• Provide a commit message to be used for the changelog entry in the PR description for review.
• Re-reviewed Files changed in the Github PR explorer.
• Review Codecov Report in the comment section below once CI passes.

[codecov-commenter]

Codecov Report

Merging #4476 (861b385) into main (d5e55b7) will not change coverage.
The diff coverage is 100.00%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4476   +/-   ##
=======================================
  Coverage   79.47%   79.47%           
=======================================
  Files         188      188           
  Lines       13045    13045           
=======================================
  Hits        10367    10367           
  Misses       2245     2245           
  Partials      433      433           

Files Changed	Coverage Δ
modules/core/04-channel/keeper/packet.go	99.10% <100.00%> (ø)

[damiannolan]

Thanks @GAtom22!

Can you confirm whether or not these errors msgs are propagated to the block's last results hash? As I understand some validators flagged this issue as reason for halt.

From investigation, I found that the error msg itself should be dropped from ExecTxResult before being put into consensus.

The error msg which is contained in the ResponseDeliverTx.Log is flagged as non-deterministic and should be stripped from results.

[GAtom22]

Thanks @GAtom22!

Can you confirm whether or not these errors msgs are propagated to the block's last results hash? As I understand some validators flagged this issue as reason for halt.

From investigation, I found that the error msg itself should be dropped from ExecTxResult before being put into consensus.

The error msg which is contained in the ResponseDeliverTx.Log is flagged as non-deterministic and should be stripped from results.

Hey @damiannolan,

For cosmos txs seems to be OK.

In Evmos this caused a LastResultsHash mismatch error because we're keeping this error message in EVM transactions (example)

[damiannolan]

Thank you @GAtom22! This had me scratching my head for a while. cc. @tac0turtle

edit: do I understand correctly that changing ANY error string would then essentially be a state machine breaking change for evmos nodes?

[GAtom22]

Not any. This is introduced with the EVM extensions that enable to use cosmos/ibc modules with EVM transactions.

We're working on handling this on our side to avoid this issue.

[damiannolan]

Not any. This is introduced with the EVM extensions that enable to use cosmos/ibc modules with EVM transactions.

We're working on handling this on our side to avoid this issue.

Makes a lot of sense! Thank you 🙏

[crodriguezvega]

Thank you, @GAtom22.