foundry
foundry copied to clipboard
Deployment info missing when using legacy feature
Component
Forge
Have you ensured that all of these are up to date?
- [ ] Foundry
- [ ] Foundryup
What version of Foundry are you on?
No response
What command(s) is the bug in?
No response
Operating System
No response
Describe the bug
First reported here
Hey, so adding --legacy tag with my deployment command, and there is no response. Usually I see something like this No files changed, compilation skipped Deployer: 0x645efC03Af16a2D8D9F67587be502830E80627A2 Deployed to: 0xcd0db8884A9EAcC5A5DAd1E4537DC8197EB5794C Transaction hash: 0xf514a9601ac7fc54336fae740a96ed1f25231d7380de789fc087b7588a4b5c68 . But with legacy there is nothing, no response although the deployment is successful. I would need the response since I run a post deployment script, so I'll need the contract addresses that were deployed. Is there a way better way to deploy multiple contracts and get their addresses ?
https://github.com/foundry-rs/foundry/issues/934#issuecomment-1191160766
@yohanelly95 could you please describe what commands you're running, I'm assuming forge create
?
Component Forge
Have you ensured that all of these are up to date?
-
[x] Foundry - updated
-
[x] Foundryup - updated
What version of Foundry are you on? forge 0.2.0 (4e141e7 2022-07-21T00:11:34.699666Z)
What command(s) is the bug in? forge create, forge script
Operating System MacOS
Hey @mattsse , so yes I tried it with forge create
and by running a script using forge script
.
my forge create command: forge create Delegator --private-key ${PRIVATE_KEY} --rpc-url ${RPC} --legacy
.
my forge script command: forge script scripts/Deploy.s.sol:DelegatorScript --rpc-url ${RPC} --private-key ${PRIVATE_KEY} --broadcast --json --legacy
Using the first forge create command the transaction is successful but foundry does not let me know, and its always stuck in the same state. Using the forge script
I get the following error:
Note: Deployments with multiple transactions always fail with the error "Invalid transaction Nonce"
and deploying a single contract using the same forge script
command:
Gets stuck in this state ^.
where Deploy.s.sol
looks something like:
import "forge-std/Script.sol";
import "forge-std/Test.sol";
import "forge-std/console.sol";
import {A} from "contracts/A.sol";
import {B} from "contracts/Core/B.sol";
import {C} from "contracts/Core/C.sol";
import {D} from "contracts/Core/D.sol";
import {E} from "contracts/Core/E.sol";
import {F} from "contracts/Core/F.sol";
import {G} from "contracts/Core/G.sol";
import {H} from "contracts/Core/parameters/H.sol";
import {I} from "contracts/randomNumber/I.sol";
import {J} from "contracts/tokenization/J.sol";
import {K} from "contracts/tokenization/K.sol";
contract DeployScript is Script, Test {
function setUp() public {}
function run() public {
vm.startBroadcast();
new A();
new B();
new C();
new D();
new E();
new F();
new G();
new H(10000e18);
new I();
new J();
vm.stopBroadcast();
}
}
@joshieDo this seems odd. Is there any chance we're not bumping the nonce in the Create hooks in the EVM broadcast (whereas we do it correctly in the Call hooks)?
Is there any chance we're not bumping the nonce in the Create hooks in the EVM broadcast (whereas we do it correctly in the Call hooks)?
Doubt it... Unless there's some real edge case. I just tried it and didnt face any issue.
@yohanelly95 What RPC (with such long chain-id...) are you using? Is it possible to have access to your repo to reproduce it?
I did some digging into it, and I tried out your network, and I had the same error.
How modified is this forked chain? I cannot get a transaction confirmation at all. May be an ethers-rs issue?
Invalid Nonce
leads to me believe that this chain does not support sending nonces bigger than the current one. If the confirmation was not an issue, I'd recommend using --slow
.
looking further, the RPC doesn't seem to be returning certain fields, which ether-rs requires on eth_getTransactionByHash
(@mattsse ). i'm not sure about what's standard though.
{ err: Error("missing field `v`", line: 1, column: 608)
2022-07-25T14:28:21.587234Z TRACE rpc{method="eth_getTransactionByHash" params="[\"0x046ef55581c848d8648811c9ba78e46f307d3bb8d948cd55c0ab9c80a9da5d42\"]"}: ethers_providers::transports::retry: should not retry err=SerdeJson { err: Error("missing field `v`", line: 1, column: 608), text: "{\"blockHash\":\"0xa4fbfeafc2ee29ee2fc188281da527dc79297a0fad560d8c70325da6b1ade407\",\"blockNumber\":\"0x15edd2\",\"from\":\"0x31a5aa527cd8879d01728b320751fced3776c703\",\"gas\":\"0x17e1d\",\"gasPrice\":\"0x186a0\",\"hash\":\"0x046ef55581c848d8648811c9ba78e46f307d3bb8d948cd55c0ab9c80a9da5d42\",\"input\":\"0x6080604052348015600f57600080fd5b50606580601d6000396000f3fe6080604052348015600f57600080fd5b506004361060285760003560e01c806330b67baa14602d575b600080fd5b00fea2646970667358221220af27cb8c88c1c6f0203648d2448bdbbcbeace28457dad16b987ca017090f58ad64736f6c634300080a0033\",\"nonce\":\"0x3\",\"to\":null,\"transactionIndex\":\"0x0\",\"value\":\"0x0\"}" }
this doesn't make any sense, because v is a mandatory field and definitely returned by eth_getTransactionByHash
, is this a response from anvil or the forked chain?
how to reproduce this?
this is from the forked chain, and it can actually be reproduced with cast tx
cast tx 0x1dbaec62a306d71fd0b2359fd5b057a980e9ede58d06867ac19596447509cb99 --rpc-url "https://staging-v2.skalenodes.com/v1/whispering-turais"
the cast tx
command fails as @joshieDo mentioned with the missing field v
.
cast receipt
is successful, eg, cast receipt 0x1dbaec62a306d71fd0b2359fd5b057a980e9ede58d06867ac19596447509cb99 --rpc-url https://staging-v2.skalenodes.com/v1/whispering-turais
and could this failure of eth_getTransactionByHash be related to the Invalid nonce
error ?
I have tried it with the --slow
command but it does not go through at the moment.
skalenetwork is not returning all the fields it should on eth_getTransactionByHash
. If you can get them to do that (issue/pr), then --slow
would work.
Invalid Nonce
leads to me believe that this chain does not support sending nonces bigger than the current one. But didn't look too deep into it.
They don't seem to be compliant (here) with the specs, so it's normal that you might have issues on using it with foundry. And for this reason, I'd close this issue, since we can't feasibly support every partially compliant network...
On further investigation it was found that, the first deployment transaction does go through, after that ethers-rs
waits for a receipt
which it does not receive, so the deployment gets stuck here (when using the --slow
flag). Hence, the rest of the transactions are not submitted, even though the initial transaction is successfully deployed to the network.
Issues with missing receipts are separate from this one and should be fixed, but if not, please open an issue for this - closing this one as per Joshie's comment