More changeset/view typing

[connorwstein]

Requires

Resolves

[github-actions]

AER Report: CI Core

aer_workflow , commit , Clean Go Tidy & Generate , Detect Changes , lint , Core Tests (go_core_tests) , Core Tests (go_core_ccip_deployment_tests) , Core Tests (go_core_race_tests) , Core Tests (go_core_fuzz) , SonarQube Scan , Flakey Test Detection

1. CSA key does not exist:go_core_ccip_deployment_tests

Source of Error:

2024-10-21T21:42:20.913Z	ERROR	chainlink/application.go:692	[Feeds Service] Failed to start CSA key does not exist	{"version": "unset@unset"}
2024-10-21T21:42:20.944Z	ERROR	chainlink/application.go:692	[Feeds Service] Failed to start CSA key does not exist	{"version": "unset@unset"}
2024-10-21T21:42:21.010Z	ERROR	chainlink/application.go:692	[Feeds Service] Failed to start CSA key does not exist	{"version": "unset@unset"}

Why: The error indicates that the Feeds Service failed to start because the CSA (Chainlink Service Agreement) key does not exist. This key is essential for the service to operate correctly.

Suggested fix: Ensure that the CSA key is correctly generated and available in the environment where the service is being started. Verify the key management and loading process.

2. rmn home address not found:go_core_ccip_deployment_tests

Source of Error:

2024-10-21T21:42:21.064Z	ERROR	changeset/initial_deploy.go:21	Failed to deploy CCIP contracts	{"version": "unset@unset", "err": "rmn home address not found: chain selector 789068866484373046: chain not found", "addresses": {"AddressesByChain":{}}}

Why: The error indicates that the deployment of CCIP contracts failed because the RMN (Remote Management Node) home address was not found for the specified chain selector. This suggests that the chain configuration is missing or incorrect.

Suggested fix: Verify that the chain configuration is correctly set up and that the RMN home address is specified for the chain selector 789068866484373046. Ensure that all necessary chain details are provided.

3. Unable to get current block:go_core_ccip_deployment_tests

Source of Error:

2024-10-21T21:42:21.065Z	ERROR	EVM.90000003.LogPoller	logpoller/log_poller.go:1049	Unable to get current block	{"version": "unset@unset", "err": "Unable to read latestBlockNumber currentBlock saved", "errVerbose": "Unable to read latestBlockNumber currentBlock saved\ngithub.com/smartcontractkit/chainlink/v2/core/chains/evm/logpoller.(*logPoller).getCurrentBlockMaybeHandleReorg\n\t/home/runner/work/chainlink/chainlink/core/chains/evm/logpoller/log_poller.go:952\ngithub.com/smartcontractkit/chainlink/v2/core/chains/evm/logpoller.(*logPoller).PollAndSaveLogs\n\t/home/runner/work/chainlink/chainlink/core/chains/evm/logpoller/log_poller.go:1045\ngithub.com/smartcontractkit/chainlink/v2/core/chains/evm/logpoller.(*logPoller).run\n\t/home/runner/work/chainlink/chainlink/core/chains/evm/logpoller/log_poller.go:650\nruntime.goexit\n\t/opt/hostedtoolcache/go/1.22.8/x64/src/runtime/asm_amd64.s:1695"}

Why: The error indicates that the LogPoller was unable to read the latest block number, possibly due to a context cancellation or timeout.

Suggested fix: Investigate the context management and ensure that the context is not prematurely canceled. Check for any network issues or timeouts that might be affecting the block reading process.

4. Error occurred while handling tx queue:go_core_ccip_deployment_tests

Source of Error:

2024-10-21T21:42:21.066Z	ERROR	EVM.90000003.Txm.Broadcaster	txmgr/broadcaster.go:323	Error occurred while handling tx queue in ProcessUnstartedTxs	{"version": "unset@unset", "err": "processUnstartedTxs failed on handleAnyInProgressTx: handleAnyInProgressTx failed: getInProgressEthTx failed: context canceled"}
2024-10-21T21:42:21.067Z	ERROR	EVM.90000003.Txm.Broadcaster	txmgr/broadcaster.go:323	Error occurred while handling tx queue in ProcessUnstartedTxs	{"version": "unset@unset", "err": "processUnstartedTxs failed on handleAnyInProgressTx: handleAnyInProgressTx failed: getInProgressEthTx failed: context canceled"}

Why: The error indicates that there was an issue processing unstarted transactions in the transaction manager's broadcaster due to a context cancellation.

Suggested fix: Ensure that the context used for transaction processing is valid and not canceled prematurely. Review the transaction handling logic to handle context cancellations gracefully.

AER Report: Operator UI CI ran successfully ✅

aer_workflow , commit

[connorwstein]

Relevant part - enforcing a signature for changesets and state viewing @krehermann @cgruber

[cl-sonarqube-production]

Quality Gate passed

Issues
1 New issue
1 Fixed issue
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube

[cgruber]

I'm not sure what this is doing, other than catching a compile error if CapRegChangeSet isn't a ChangeSet.

[cgruber]

Having an explicit Changeset (and view state) notion makes sense to me.

I'm trying to roll around the idea that it's a function-type, rather than an interface. You can pull in an interface, but I don't see where we're forcing correct types, except in the unused var, which looks like a convention we could forget, rather than a type we have to conform to to even use the system. Or is there something I'm missing here? Is there a place where we consume (formally, so the compiler can enforce it) the ViewState and Changeset functions?

I guess this is fine in the sense that there isn't necessarily any reason for a struct with any particular data, if these are pure functions anyway, but is there any functionality that attaches to a change set, any metadata about the changeset, that we envision?

I guess it's not terribly hard to fix later, I'm just trying to get a sense of where we want it to go.