txIter
returns an iterator that runs with constant timestamp even when blockchain.now
is manually modified
#57
Labels
bug
Something isn't working
Describe the bug
Developers have freedom to modify
blockchain.now
as needed. However, when one wants to usesendMessageIter
and updateblockchain.now
as each message gets executed, all messages will actually have a constant timestamp because of this:sandbox/src/blockchain/Blockchain.ts
Lines 306 to 315 in fe0fc3b
params
will havenow: this.now
, which will stay constant becausethis.now
is just a plain number, not a reference to an object. As the iterator returned by this function iterates, each transaction executed by this iterator will always have the same timestamp that was given at the beginning, even ifblockchain.now
is manually updated to something else.To Reproduce
An example repository has been provided at https://github.com/9oelM/ton-sandbox-bug.git:
The test is simple. It sends a message using
blockchain.sendMessageIter
andexecuteTill
, and checks timestamp at each step. The contracts are configured to~dump([contractId, now()])
when they receive a message, so we can check the timestamp when the contract actually runs.The logs show that while
blockchain.now
increments by 1000,now()
called inside the contract returns the initialblockchain.now
it started with.Expected behavior
If it were correctly run, the debug logs from the contract must be:
#DEBUG#: s0 = [1 1733802917]
and#DEBUG#: s0 = [2 1733803917]
because the timestamp in the contract needs to be in sync withblockchain.now
.Actual behavior
The timestamp in the contract fails to follow
blockchain.now
when it gets manually updated.System information
Solution
To fix this problem, we just need to introduce a
now
parameter tonext
function that will override the originalnow
parameter passed down fromparams
:sandbox/src/blockchain/Blockchain.ts
Lines 389 to 391 in fe0fc3b
Above code must be modified as follows:
Also, because
executeTill
andexecuteFrom
depend onnext()
, they need to have an additional parameter specifyingnow
too:Or another way to handle this would be to read from
blockchain.now
directly and override it. Thie approach would not requireexeuteTill
andexecuteFrom
to be fixed, becausenext()
will always follow the latestblockchain.now
:Ultimately, this depends on the design decision of the SDK.
Anyway, once you fix things, you will be able to see the test working correctly as intended:
The text was updated successfully, but these errors were encountered: