[IMPROVEMENT] Make E2E Tests Resilient to Foundry Version Differences
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 38/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- shell, solidity
- Lĩnh vực
- blockchain, testing
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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
- Ngôn ngữ chính
- Cadence
- Star
- 41
- Fork
- 0
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của onflow/FlowYieldVaults
-
Clarify contract version namingĐang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 25/100
onflow/FlowYieldVaults#274 ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
onflow/FlowYieldVaults#273 ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
onflow/FlowYieldVaults#272 ·
-
Remove outdated documentationĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 35/100
onflow/FlowYieldVaults#271 ·
-
Move all test files into `./cadence/tests`Có thể làm lại được Pull request cho issue này đã bị đóng mà không được merge. Đang mở
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 35/100
onflow/FlowYieldVaults#270 ·
Tất cả issue của onflow/FlowYieldVaults
Issue tương tự
-
bug Good First Issue Candidate
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
hiero-ledger/hiero-sdk-js#4656 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Add API: BlockVectra Data APIĐang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 74/100
Maintainer thường phản hồi trong vòng 2 ngày
-
send
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
trezor/trezor-suite#34248 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 82/100
velocity-exchange/velocity-v1#572 ·
Maintainer thường phản hồi trong vòng 1 ngày