-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BCF-2492 Remove evm default chain id #10490
Conversation
- Remove default chain id from LegacyChainContainer - Add alternate function for default chainID in tests
I see that you haven't updated any README files. Would it make sense to do so? |
I see that you haven't updated any CHANGELOG files. Would it make sense to do so? |
- Remove default chain id from LoopRelayAdapter - Remove default chain id use from common.go getChain - Remove default chain id use from evm relayer init
- Remove code that relied on default chainID
- Fix evm transfer controller tests - Fix integration test helpers - Fix head tracker tests - Fix evm transaction commands test
…fault-evm-chainID # Conflicts: # core/internal/cltest/mocks.go # core/services/chainlink/relayer_chain_interoperators.go # core/services/relay/evm/mocks/loop_relay_adapter.go # core/services/relay/evm/relayer_extender.go
Running downstream job at https://github.com/smartcontractkit/operator-ui/actions/runs/6108992813 |
Running downstream job at https://github.com/smartcontractkit/operator-ui/actions/runs/6109652266 |
Running downstream job at https://github.com/smartcontractkit/operator-ui/actions/runs/6121157137 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very good! I've been wanting to see this gone for years
Normally we would provide a migration to auto-upgrade the jobs so that this is a non-issue. Was this considered? |
…fault-evm-chainID # Conflicts: # core/cmd/shell_remote_test.go # core/web/common.go
I think I didn't explain the issue properly, there wouldn't be any issue with existing created jobs, just with old job specs that don't have evmChainID defined, depending on how NOPs usually store jobspecs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I only looked at keystore migration code, but removing all of that looks wonderful to me :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's add something to the change log
SonarQube Quality Gate |
Remove all usage of default chainID:
CreateJob
that checks if evmChainID is defined for every job type that has EVMChainID in its specFor all job specs evmChainID field got injected with the default chain ID on job creation so all existing jobs would be valid. But if NOPs externally stored some old job specs, they won't have evmChainID defined in them and after these changes get merged evmChainID won't be implicitly injected anymore. I talked to Brendon and this should be fine.
Also a lot of tests relied on DefaultChainID, so most of the changes are to pass evmChainID where needed in tests.