0.2.6 Release #46
0.2.6 Release #46
Conversation
…axAnswer functions. Add functionality to MockV3Aggregator to change underlying aggregator
* feat: Add new changes to support CCIP v1.5 version * forge: Update ccip
…tnet lanes. Prepare for 0.2.2-beta.0 release (#21)
…hainAndRouteMessage function of CCIPLocalSimulatorFork (#23)
- Bump @chainlink/contracts-ccip to v1.5.0 - Delete DOCUMENTATION.md and related assets, and point to official documentation at README - Update CHANGELOG
* feat: Add mock data streams contracts * feat: smoke test data streams in local mode in Foundry with docs examples * feat: Add GMX-like test example * feat: Add DataStreamsLocalSimulatorFork implemented in both Solidity and JavaScript * feat: Add MockReportGenerator.js to support local mode in Hardhat; Support Forking mode in Hardhat * chore: Prepare for 0.2.4-beta release * chore: Generate docs artifacts
…er) with chainlink-local versioning (#31) Co-authored-by: emanherawy <[email protected]>
* chore: Bumped @chainlink/contracts to 1.3.0. Started returning raw report structs from generateReportV- functions which is handful for tests * chore: Generate docs artifacts for this adjustment
* chore: Bumped @chainlink/contracts to 1.3.0. Started returning raw report structs from generateReportV- functions which is handful for tests * chore: Generate docs artifacts for this adjustment * fix: Year should be 2025 instead of 2024
* fix: Fix incorrect import path * chore: Prepared changelog and package.json for v0.2.4-beta.1 release
g the commit.
* feat: Add support for CCIP v1.6 * chore: Removed lib/ccip and lib/chainlink-brownie-contracts dependencies * fix: Accept copilot's suggestions
…o v1.4.0 and @chainlink/contracts-ccip to v1.6.0
* fix: Refactored CCIPLocalSimulatorFork.sol so it can route all CCIP messages sent from a loop and not just the first one * fix: Correct loop variable k
* fix: Refactor switchChainAndRouteMessage to deliver more than 1 message to more than 1 chain in a same call * chore: Ran `npm run generate-docs` * fix: Correct offRamp index in executeSingleMessage call in CCIPLocalSimulatorFork
There was a problem hiding this comment.
Pull Request Overview
This PR prepares the Chainlink Local project for version 0.2.6 release, introducing enhanced CCIP message routing capabilities. The main improvement allows users to simulate sending multiple CCIP messages to single or multiple destination chains simultaneously.
Key changes:
- Added overloaded
switchChainAndRouteMessage(uint256[] forkIds)function for multi-destination routing - Refactored message routing logic to handle multiple messages and destinations in a single call
- Updated version number from 0.2.5 to 0.2.6
Reviewed Changes
Copilot reviewed 8 out of 9 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| src/ccip/CCIPLocalSimulatorFork.sol | Major refactor of routing logic with new array-based function and consolidated message processing |
| test/e2e/ccip/LooperFork.t.sol | New test file demonstrating multi-chain message routing capabilities |
| package.json | Version bump to 0.2.6 |
| api_reference/solidity/ccip/CCIPLocalSimulatorFork.mdx | Documentation updates for new routing functions |
| api_reference/javascript/CCIPLocalSimulatorFork.mdx | Added documentation for new message parsing function |
| api_reference/solidity/shared/ITypeAndVersion.mdx | New API documentation file |
| api_reference/solidity/shared/index.mdx | Index update to include ITypeAndVersion |
| CHANGELOG.md | Release notes for version 0.2.6 and beta versions |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
| * | ||
| * @param forkIds - The IDs of the destination network forks. These are the returned values of `createFork()` or `createSelectFork()` | ||
| */ | ||
| function switchChainAndRouteMessage(uint256[] memory forkIds) external { |
There was a problem hiding this comment.
Rather than overload is it not better to have switchChainAndRouteMessages? Is there a specific advantage to overloading? since the two functions need to be separately implemented anyway, would it not be better to disambiguate their names?
There was a problem hiding this comment.
the switchChainAndRouteMessage(uint256 forkId) now can also deliver multiple messages, but I could't rename it to switchChainAndRouteMessages(uint256 forkId) because that would break backwards compatibility. So I kept everything consistent.
| import {IERC20} from | ||
| "@chainlink/contracts/src/v0.8/vendor/openzeppelin-solidity/v4.8.3/contracts/token/ERC20/IERC20.sol"; | ||
|
|
||
| contract Looper is CCIPReceiver { |
There was a problem hiding this comment.
Nice test!
Only feedback here is "Looper" not very clear or domain-specific. It makes sense to us because we already know what it does, but to someone else it can be confusing.
A better name for the Contract/Object and also this test file would reflect its role as a CCIP bulk/multi message sender & receiver for testing or simulation.
something like MultiSender or something? Have a think!
There was a problem hiding this comment.
Oh it is a terrible name and a terribly written test, but this was a very high priority so I left it as is lol...will tidy it up (and bunch of other tests) in the upcoming releases
This PR prepares Chainlink Local for 0.2.6 release. For more details, try the 0.2.6-beta.0 release.
The main change is that now one can:
We accomplished that by introducing the new
switchChainAndRouteMessage(uint256[] forkIds)function which is an overlap of an existingswitchChainAndRouteMessage(uint256 forkId)function.How to use it?
switchChainAndRouteMessage(uint256 forkId)switchChainAndRouteMessage(uint256 forkId)(it will deliver all messages, not just the first one)switchChainAndRouteMessage(uint256[] forkIds)(one can pass chains A, B, C here, it will deliver all messages to their target chains without duplication)Basically no matter when one calls it, it will loop through all unprocessed CCIP messages and try to deliver them to appropriate destination chains. However, keep in mind that if one doesn’t pass correct forkIds, undelivered messages would be lost due to nature of Foundry.