meta(script): tracking issue for script improvements

[mds1]

roughly prioritized/sorted, still a work in progress

High Priority

These are high priority because they block deployment, and user's need to find workarounds or user other tools as a result

• Failed to estimate gas for CREATE2 deployment on Arbitrum #2941
• Using a script to send transactions deploying contracts and sending ether Not Working on goerli arbitrum #4566
• Getting exceeds block gas limit error on forge script deployment #3294
• Multichain deployment gives EOA nonce changed unexpectedly while sending transactions #4701

Library Issues

• Nested library linking results in duplicate deployments #2607
• forge script deploys libraries used outside of vm.start/stopBroadcast #3924
• Discussion in meta(library linking): tracking issue for library linking improvements #4443
• Cheatcode supporting the deployment of linked libraries in scripts #3664
• bug(forge script): libraries that are used in a deployment are deployed even if their use isn't within a vm.start/stopBroadcast #3295
• Create2 deployment by script does not use create2 to deploy libraries #4810

Ledger Issues

• Sequence mismatch. Got 1 from device. Expected 0 #3266
• Multi chain deployment script issues (Ledger, --verify)  #3698
• Ledger --hd-paths returns "Ledger device not available" #4692

Other

These are not yet sorted

• forge script CLI crashes #4857
• Ability to detect different "environments" in scripts/tests #2900
• feat(forge script): add ability to replay failed transaction on a local anvil fork #2673
• Script: support matching --sig argument with function hex selector #4325
• bug: remove sensitive info from broadcast files #4730
• Don't keep CALLER balance as U256::MAX #2390 (specifically this comment)
• forge script --json always returns a zero status #2508
• Consider renaming fields and changing types in the broadcast JSON output files #2987
• bug: remove sensitive info from broadcast files #4730
• remove initial version that has no receipts if forge script was successful atomically
• Able to custom maxPriorityFeePerGas on Solidity-Scripting #3642
• In broadcast log, include arg names and use standard syntax #3887
• Forge script crashes when two script contracts have the same name. #3177
• feat: vm.confirmContinue cheat code #2399 (comment)
• forge script --watch is not watching anything #4476 (comment)
• feat: cheatcode to get recent deployments by contract name #4732
• Can't run multiple forge script in parallel #2884

[odyslam]

Based on our experience in making multiple deployments in December 2022, a big takeaway was that the transaction lifecycle management needed rework.

Due to unreliable RPC providers and network issues, the foundry script should be more robust in handling these issues and issuing the proper transactions in the appropriate order.

Relevant issues are being discussed afaik in the ethers-rs telegram, so I understand that the required work is part foundry script, part ethers-rs.

The TL;DR is that the forge script should be more robust and recover from more failures without the user resorting to multiple --resume executions.

[sambacha]

Based on our experience in making multiple deployments in December 2022, a big takeaway was that the transaction lifecycle management needed rework.

Due to unreliable RPC providers and network issues, the foundry script should be more robust in handling these issues and issuing the proper transactions in the appropriate order.

Relevant issues are being discussed afaik in the ethers-rs telegram, so I understand that the required work is part foundry script, part ethers-rs.

The TL;DR is that the forge script should be more robust and recover from more failures without the user resorting to multiple --resume executions.

Why not just let users submit bundles instead of individual transactions? That removes a lot of issues.

No need to recover if atomic.

[mds1]

I agree that would be a nice feature, but it only helps on mainnet when the total bundle uses <30M gas, so it doesn’t solve the problem for all users and all chains

[sambacha]

I agree that would be a nice feature, but it only helps on mainnet when the total bundle uses <30M gas, so it doesn’t solve the problem for all users and all chains

Ethereum mainnet is the relevant chain. Supporting submission via bundles can be adopted downstream by other chains.

Transaction submission bundling isn't about gas usage per se, it's about atomic deployment.

The case about other users and other chains is irrelevant, as it does not worsen their situation.