Add unpeer to unwire logic#562
Conversation
… task inherits the onesig flag
|
There was a problem hiding this comment.
Pull request overview
Adds “unwire” tooling for messaging contracts by extending existing wiring flows to also unpeer messaging edges (set peer to bytes32(0)), plus introduces an operational check to verify deprecated chains are fully disconnected.
Changes:
- Introduces new Hardhat tasks to unwire TokenMessaging/CreditMessaging (disable executor/DVN + unpeer edges) and to unpeer by EID when a chain is already removed from configs.
- Adds a “messaging disconnected” check task + YAML config, and wires new Makefile targets.
- Extends unwire YAML config parsing to support directional unwire rules (
from/to/both) and centralizes TASK_LZ_OAPP_WIRE--onesigsigner override logic.
Reviewed changes
Copilot reviewed 11 out of 11 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
| packages/stg-evm-v2/devtools/tasks/wireTaskSetup.ts | Centralizes TASK_LZ_OAPP_WIRE extension (--onesig) and sign-and-send override, exports wireTask. |
| packages/stg-evm-v2/devtools/tasks/unwireMessaging/unwireMessaging.ts | Adds unwire tasks (token/credit) and an EID-based unpeer task. |
| packages/stg-evm-v2/devtools/tasks/index.ts | Switches to shared wireTaskSetup + registers new task modules. |
| packages/stg-evm-v2/devtools/tasks/constants.ts | Adds task name constants for unwire + disconnected-check tasks. |
| packages/stg-evm-v2/devtools/tasks/checkMessagingDisconnected/messaging.disconnected-check.yml | Provides default deprecated EID list for the disconnected check. |
| packages/stg-evm-v2/devtools/tasks/checkMessagingDisconnected/config.ts | Loads/validates YAML config for the disconnected check task. |
| packages/stg-evm-v2/devtools/tasks/checkMessagingDisconnected/checkMessagingDisconnected.ts | Implements the disconnected-check task across all live chains. |
| packages/stg-evm-v2/devtools/config/utils/unwire.config.utils.ts | Adds direction support to unwire rules and applies it when generating disallowed edges. |
| packages/stg-evm-v2/devtools/config/mainnet/01/chainsConfig/unwire/0-template-messaging.unwire.yml | Documents the new direction field in the template. |
| packages/stg-devtools-v2/src/messaging/config.ts | Adds configureUnpeerEdges configurator to produce setPeer(eid, null) transactions. |
| Makefile | Replaces old unwire targets with new unwire-chain targets and adds disconnected-check target. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| # Verifies that the listed deprecated chains are fully disconnected from all active chains. | ||
| # Run with: STAGE=mainnet make check-messaging-disconnected |
There was a problem hiding this comment.
I don't love the comment, this file is the config for the checker, not the checker, so it doesn't "verify".
| # deprecated_eids: EIDs of chains that should no longer be peered with anyone. | ||
| # Can be a single value or a list. | ||
| # | ||
| # active_chains (optional): names of chains to check against. | ||
| # If omitted, all chains currently supporting messaging are checked. |
There was a problem hiding this comment.
I'd clarify that we're using EIDs for deprecated chains since we don't have chainsConfig/*.yml anymore.
As a side-note, I think it's cleaner to keep the source of truth in chainConfig/, that way it's less spread.
| } | ||
| const allowedPeers = normalizeChainList(rule.allowed_peers, 'allowed_peers', configPath, 'Messaging unwire') | ||
| return { chain: rule.chain, allowedPeers } | ||
| const direction: UnwireDirection = rule.direction ?? 'both' |
There was a problem hiding this comment.
I'd prefer throwing in the following error if unset or malformed rather than defaulting to 'both'.
There was a problem hiding this comment.
I believe we should be persisting these configurations for traceability?
| (args: SubtaskConfigureTaskArgs<TokenMessagingOmniGraph, ITokenMessaging>, hre, runSuper) => | ||
| runSuper({ | ||
| ...args, | ||
| configurator: createConfigureMultiple(configureTokenMessaging, configureUnpeerEdges), |
There was a problem hiding this comment.
Since configureTokenMessaging and configureUnpeerEdges are executed in the same run, can the following happen?
- Chain A is already unpeered.
configureTokenMessagingtries to peer it.configureUnpeerEdgesis a no-op, since it's already unpeered.
We get re-wirings instead of no-ops?
Should we drop configureUnpeerEdges and make configureTokenMessaging run setPeer(0)?
No description provided.