[IMPROVEMENT] Make E2E Tests Resilient to Foundry Version Differences
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 38/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- shell, solidity
- Ambito
- blockchain, testing
Direzione di ricerca
Start by reading local/punchswap/e2e_punchswap.sh and solidity/script/02_DeployUSDC_WBTC_Create2.s.sol to trace how token addresses are predicted and used. Then inspect local/punchswap/punchswap.env and solidity/script/03_UseMintedUSDCWBTC_AddLPAndSwap.s.sol for the configured addresses and strategy initialization. Done means the E2E flow uses addresses that match deployed tokens across supported Foundry versions; the issue also proposes documenting the tested version in the README.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Issue to be solved
When running the e2e test script (e2e_punchswap.sh), the predicted addresses of USDC and WBTC tokens differ depending on the Foundry version installed locally. This address mismatch causes:
- E2E tests to fail or not complete successfully
- FlowVaultsStrategies contract to be initialized with hardcoded addresses (e.g.,
0xaCCF0c4EeD4438Ad31Cd340548f4211a465B6528) that don't actually have ERC20 tokens deployed at them - Runtime interaction failures when working with the emulator because strategies reference non-existent token contracts
Current Behavior
The deployment script 02_DeployUSDC_WBTC_Create2.s.sol uses Foundry's CREATE2 deployer to predict token addresses:
address predictedUSDC = _predict(CREATE2_DEPLOYER, SALT_USDC, usdcInit);
address predictedWBTC = _predict(CREATE2_DEPLOYER, SALT_WBTC, wbtcInit);
These predicted addresses are then:
- Used as configuration values in
punchswap.env:USDC_ADDR=0xaCCF0c4EeD4438Ad31Cd340548f4211a465B6528WBTC_ADDR=0x374BF2423c6b67694c068C3519b3eD14d3B0C5d1
- Passed as initialization arguments when deploying FlowVaultsStrategies
However, different Foundry versions appear to generate different predicted addresses for the same deployment parameters, breaking the entire deployment and testing flow.
Impact
- Test Reliability: E2E tests are not reproducible across different development environments
- Configuration Mismatch: Hard-coded addresses in
punchswap.envdon't have actual ERC20 tokens deployed at them when Foundry versions differ - Deployment Failures: FlowVaultsStrategies contracts are initialized with addresses that point to empty/non-token contracts, causing all token interactions to fail
- Team Coordination: Different team members may experience different test results based on their local Foundry installation
Suggest A Solution
Inform Foundry Version to be used locally
Technical Implementation:
-
Document the working Foundry version in README:
This project has been tested with: forge Version: 1.4.3-v1.4.3 Commit SHA: fa9f934bdac4bcf57e694e852a61997dda90668a Build Timestamp: 2025-10-22T04:37:38.758664000Z Build Profile: maxperfTo install this specific version:
foundryup --version nightly-fa9f934bdac4bcf57e694e852a61997dda90668a
Tradeoffs:
- ✅ Simple to implement
- ✅ Provides clear guidance to developers
- ❌ Relies on developers manually checking and installing correct version
- ❌ No automated enforcement
Caveats and Considerations for the Future
-
CI/CD Integration: Whichever solution is chosen should work seamlessly in GitHub Actions and other automated environments
-
Address Registry: For long-term maintainability, consider implementing a deployment address registry pattern (similar to what protocols like Aave use) where all contract addresses are stored in a central registry contract or JSON file
Related Files
local/punchswap/e2e_punchswap.sh- E2E test orchestration scriptsolidity/script/02_DeployUSDC_WBTC_Create2.s.sol- Token deployment with CREATE2local/punchswap/punchswap.env- Configuration file with hard-coded addressessolidity/script/03_UseMintedUSDCWBTC_AddLPAndSwap.s.sol- Strategy deployment using predicted addresses
What are you currently working on that this is blocking?
No response
- Lingua principale
- Cadence
- Stelle
- 41
- Fork
- 0
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di onflow/FlowYieldVaults
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
onflow/FlowYieldVaults#274 ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
onflow/FlowYieldVaults#273 ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
onflow/FlowYieldVaults#272 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 35/100
onflow/FlowYieldVaults#271 ·
-
Move all test files into `./cadence/tests`Forse di nuovo libera Una pull request per questa issue è stata chiusa senza essere unita. Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 35/100
onflow/FlowYieldVaults#270 ·
Tutte le issue di onflow/FlowYieldVaults
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
btclib-org/btclib-node#1833 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 Meno di un'ora Idoneità per principianti 85/100
ethersphere/bee#5652 ·
I maintainer di solito rispondono entro 2 giorni
-
enhancement good first issue help wanted
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
-
Request: add {USDT Lis}Apertalist-request
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
Uniswap/tokenlists-org#3325 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100