Open
Description
It is currently (as far as I can tell) impossible to trace a transaction that has happened in the future, as might happen in a development environment when using helpers.
Running npx hardhat node
in one console, in another inside a npx hardhat console
connected to the node:
<Command to do Transaction 1>
{ time } = await import("@nomicfoundation/hardhat-network-helpers")
time.increase(1000000000)
<Command to do Transaction 2>
If you now try and trace those transactions:
npx hardhat trace --hash <tx1 hash> --rpc http://127.0.0.1:8545
This command works
npx hardhat trace --hash <tx2 hash> --rpc http://127.0.0.1:8545
This does not work, and fails with:
Nothing to compile
Activating mainnet fork at block 4
thread 'tokio-runtime-worker' panicked at /build/crates/edr_provider/src/data.rs:2464:18:
current time must be after fork block: SystemTimeError(999999463.793941211s)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
An unexpected error occurred:
[Error: task 37 panicked] { code: 'GenericFailure' }
This error is being thrown here
I was unsure whether to make this here or in the EDR repository directly, but I see @fvictorio is active in this repository as well, so I am hopeful it will end up in the right place regardless!
I haven't tried with a pre-EDR version of hardhat, so do not know if this a regression.
Metadata
Assignees
Labels
No labels
Activity
fvictorio commentedon Jul 18, 2024
Hey @area, there's definitely something weird going on here, but something that caught my attention is your use of
--rpc http://127.0.0.1:8545
. I think you meant to use--network localhost
instead, if the intention was to run the trace in the node?I don't fully understand what
--rpc
does inhardhat-tracer
, but it seems to me that it expects a "real node" URL (e.g., a synced local node, or a service provider like Alchemy).area commentedon Jul 18, 2024
I can't claim to know exactly what's going on either! However, when trying to use
--network localhost
in place of--rpc
or equivalent I getI assumed that this was something to do with not tracing against an 'in-process' node and didn't think much further about it, but if this could be a symptom of something related that's not working, happy to explore further.
fvictorio commentedon Jul 18, 2024
That's weird, can you double-check that you are using the latest versions of Hardhat and
hardhat-tracer
?area commentedon Jul 18, 2024
I appear to be. Full reproduction steps for that side of things, for you, using
openzeppelin
's repository:Download this patch for the hardhat config and apply with
git apply hh.patch.txt
from the repository root: hh.patch.txtThen in one console:
npx hardhat node --trace
(I've tried with and without--trace
, with the same result either way)In a second console:
And then:
fvictorio commentedon Jul 19, 2024
In that case this seems like a problem on the
hardhat-tracer
side. I'll let @zemse take a look first, but happy to help if needed.zemse commentedon Jul 22, 2024
Sorry I was afk last week. I will look into this problem tomorrow and try to fix it.
fix trace task (#74)
add test case involving evm_increaseTime (#74)
zemse commentedon Aug 5, 2024
Sorry for the long delay.
I have tried a fix.
npx hardhat node --trace
had a problem, it wasn't collecting traces, now should collect the traces. I've also re-implemented the trace task to handle the case when rpc is a hardhat node, it would attempt to pull trace data directly through a custom rpctracer_getTrace(txHash)
otherwise fallback to mainnetfork debug tracing.Can you please try the release
hardhat-tracer@3.1.0
?area commentedon Aug 6, 2024
This appears to now be possible when using
npx hardhat node --trace
, though my reproduction steps in the opening post result in the same error as before when using justnpx hardhat node
.--network localhost
and--rpc http://127.0.0.1:8545
now seem to behave the same in each case.zemse commentedon Aug 6, 2024
I was able to reproduce this problem when using
npx hardhat node
(without--trace
). Can you confirm if you used --trace while starting node or not?If
--trace
is used while starting hardhat node then it will record and store traces for the locally executed transactions andnpx hardhat trace --rpc <url>
will simply make an RPC calltracer_getTrace
with the tx hash and display the trace, this is preferred. This flow should avoid the forking and the original error.Without the
--trace
on the node, the trace task would create a fork and that's where error is coming in this case.Here are steps to reproduce outside of hardhat tracer.
Terminal 1:
Terminal 2:
Terminal 3:
cc @fvictorio The reason I am doing hardhat_reset is to be able to replay remote transactions locally on EDR. Is it possible to allow remote blocks to use future timestamp? Given that many startups these days offer customisable private testnets RPCs which might have future timestamp. Or maybe a flag that allows for it?
area commentedon Aug 6, 2024
Maybe my original message was unclear, but I think we're in agreement - when using
--trace
, the issue does not appear. But when just usingnpx hardhat node
, it is still present.