You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm currently running forge script programmatically and found out about the --json flag which is perfect for my use case where I'd need to retrieve the traces. Unfortunately it seems there is an issue with the decoded data payload in the traces.
When running the script on a fork, it seems that the complete execution traces in the json format lack all the decoding data. What hints as this being a bug is that the second payload in the output, the one containing the simulated on-chain traces section, actually has the decoded data, for a call identical to the one made in the simulation traces.
Here's the output without the --json flag (don't mind the weird input data, it's only for testing purposes)
No files changed, compilation skipped
Traces:
[11754] MyScript::run([0x9A6034c84cd431409Ac1a35278c7Da36FfDa53E5], Value({ val: 1234, for_fun: [0x9A6034c84cd431409Ac1a35278c7Da36FfDa53E5, 0x9A6034c84cd431409Ac1a35278c7Da36FfDa53E5, 0x9A6034c84cd431409Ac1a35278c7Da36FfDa53E5] }), [0x9A6034c84cd431409Ac1a35278c7Da36FfDa53E5, 0x9A6034c84cd431409Ac1a35278c7Da36FfDa53E5, 0x9A6034c84cd431409Ac1a35278c7Da36FfDa53E5], "omg", 57896044618658097711785492504343953926634992332820282019728792003956564819967 [5.789e76])
├─ [0] VM::startBroadcast()
│ └─ ← [Return]
├─ [0] another_one::test()
│ └─ ← [Stop]
├─ [0] VM::stopBroadcast()
│ └─ ← [Return]
└─ ← [Stop]
Script ran successfully.
## Setting up 1 EVM.
==========================
Simulated On-chain Traces:
[0] another_one::test()
└─ ← [Stop]
Warning: Script contains a transaction to 0x9A6034c84cd431409Ac1a35278c7Da36FfDa53E5 which does not contain any code.
==========================
Chain 1
Estimated gas price: 1.381970521 gwei
Estimated total gas used for script: 29094
Estimated amount required: 0.000040207050337974 ETH
==========================
=== Transactions that will be broadcast ===
Chain 1
### Transaction 1 ###
accessList []
chainId 1
gasLimit 29094
gasPrice
input 0xf8a8fd6d
maxFeePerBlobGas
maxFeePerGas
maxPriorityFeePerGas
nonce 1
to 0x9A6034c84cd431409Ac1a35278c7Da36FfDa53E5
type 0
value 0
SIMULATION COMPLETE. To broadcast these transactions, add --broadcast and wallet configuration(s) to the previous command. See forge script --help for more.
Transactions saved to:
.../broadcast/MyScript.s.sol/1/dry-run/run-latest.json
Sensitive values saved to:
.../cache/MyScript.s.sol/1/dry-run/run-latest.json
Here we can see that the test() call gets properly decoded (even the VM call is)
Now here are the two json payloads I get with the --json flag
First, the complete simulation traces, including script deployment
Hi @mortimr thanks for raising this, there are some parts of Foundry that do not fully support the --json flag due to mixed output modes. I'll mark this as a feature request.
Component
Forge
Have you ensured that all of these are up to date?
What version of Foundry are you on?
forge Version: 1.0.0-stable Commit SHA: e144b82 Build Timestamp: 2025-02-13T20:02:34.979686000Z (1739476954) Build Profile: maxperf
What version of Foundryup are you on?
foundryup: 1.0.1
What command(s) is the bug in?
forge script
Operating System
macOS (Apple Silicon)
Describe the bug
Hey !
I'm currently running
forge script
programmatically and found out about the--json
flag which is perfect for my use case where I'd need to retrieve the traces. Unfortunately it seems there is an issue with the decoded data payload in the traces.When running the script on a fork, it seems that the complete execution traces in the json format lack all the decoding data. What hints as this being a bug is that the second payload in the output, the one containing the
simulated on-chain traces
section, actually has the decoded data, for a call identical to the one made in the simulation traces.Here's the output without the
--json
flag (don't mind the weird input data, it's only for testing purposes)Here we can see that the
test()
call gets properly decoded (even theVM
call is)Now here are the two json payloads I get with the
--json
flagFirst, the complete simulation traces, including script deployment
And here is the second payload, with only broadcasted calls. Here we can see that the decoded data section includes the label and call info.
So I'm guessing there is an issue with the forwarded decoded data for the first payload.
The text was updated successfully, but these errors were encountered: