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

gnodev time.Now() values are not preserved on reload #1509

Open
jefft0 opened this issue Jan 10, 2024 · 1 comment · May be fixed by #2943
Open

gnodev time.Now() values are not preserved on reload #1509

jefft0 opened this issue Jan 10, 2024 · 1 comment · May be fixed by #2943
Assignees
Labels
🐞 bug Something isn't working

Comments

@jefft0
Copy link
Contributor

jefft0 commented Jan 10, 2024

In gnodev, preserve time.Now() values on reload

Description

In gnodev, the reload operation replays all the transactions. In general this lets the realm functions restore the state. But if some realm functions use time.Now() then this returns the (arbitrary) time of reload, not the time of the original transaction. Therefore, reload does not actually restore the state.

Your environment

  • macOS Ventura 13.6.3
  • Go 1.20.7
  • Latest gnolang/gno as of posting
  • Latest commit: c6097cd

Steps to reproduce

  • Set up the test1 key for gnokey
  • Install gnodev
  • Start gnodev
  • Register the test1 user, create a board and post with CreateThread as follows:
gnokey maketx call -pkgpath "gno.land/r/demo/users" -func "Register" -args "" -args "test_1" -args "Profile description" -gas-fee "10000000ugnot" -gas-wanted "2000000" -send "200000000ugnot" -broadcast -chainid tendermint_test -remote 127.0.0.1:36657 test1
gnokey maketx call -pkgpath "gno.land/r/demo/boards" -func "CreateBoard" -args "myboard" -gas-fee "1000000ugnot" -gas-wanted "5000000" -broadcast -chainid tendermint_test -remote 127.0.0.1:36657 test1
gnokey maketx call -pkgpath "gno.land/r/demo/boards" -func "CreateThread" -gas-fee 1000000ugnot -gas-wanted 5000000 -broadcast -chainid tendermint_test -args "1" -args " mytitle" -args "post at <current UTC time>" -remote "127.0.0.1:36657" test1

Expected behaviour

The boards realm uses time.Now() for the displayed post time. Reload should restore the realm state including timestamps from time.Now()

Actual behaviour

The timestamps of all message have the time of reload, erasing important information. This is because to reload gnodev resends the transactions where the block time is the current time of reload. This same timestamp is returned by every call to time.Now() .

(Related, the boards realm in testnet3 was built by replaying transactions, similarly to gnodev reload. The original message timestamps are erased and are set to the same value "2023-08-18 11:44am UTC". https://test3.gno.land/r/demo/boards:testboard .)

Proposed solution

One possible solution: The transaction processing code should have an option to specify the block time. Instead of using a high-level broadcast during replay, gnodev should call the lower-level transaction processing code and supply the correct timestamp of the original transaction. This will be used by time.Now().

Here are the message times before reload:
Screenshot 2024-01-10 at 10 15 01

Here is where all timestamps are reset after reload:
Screenshot 2024-01-10 at 10 17 17

⚠️ Risks and impact if not fixed

A realm developer can't use gnodev with any realm that relies on time.Now(). For example:

  • Timestamps on posted messages, or any time-based calculations like "number if messages in the last day".
  • There are hacks to avoid using time.Now() but they introduce security risks of not having reliable timestamps from the transaction.
  • The long-term technique to do realm versioning may also solve this problem by replaying transactions, and so this also needs to be addressed in this case.
@moul
Copy link
Member

moul commented Jan 12, 2024

Depends on #1511
Related with #1108

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐞 bug Something isn't working
Projects
Development

Successfully merging a pull request may close this issue.

3 participants