Refactor ccip launcher to mirror on chain state(CCIP-2687) #15065
Conversation
0xAustinWang
changed the title
|
I see you updated files related to
|
AER Report: CI Core ran successfully ✅AER Report: Operator UI CI ran successfully ✅ |
0xAustinWang
changed the title
0xAustinWang
force-pushed
the
ccip/launcherRefactor
branch
from
784d3fe to
907c251
Compare
0xAustinWang
requested review from
chudilka1,
winder,
rstout,
asoliman92,
makramkd,
dimkouv,
mateusz-sekara and
0xnogo
0xAustinWang
force-pushed
the
ccip/launcherRefactor
branch
from
9477792 to
9fc3236
Compare
| // This shuts down instances that were present previously, but are no longer needed | ||
| for digest, oracle := range prevPlugins { | ||
| if _, ok := c[digest]; !ok { | ||
| err = multierr.Append(err, oracle.Close()) |
There was a problem hiding this comment.
nit: I believe we could close them in parallel to get some performance boost.
Also maybe it's easier to use sets i.e. mapset for figuring out which oracles needs to be closed and which ones are new.
old = someSet()
new = someSet()
close = old - new
open = new - old
There was a problem hiding this comment.
Ha interesting thing is that this set sub logic is mirrored in the diff code. Maybe needs a lib to unify 🤔
There was a problem hiding this comment.
There was a problem hiding this comment.
Updated to start and close in parallel.
In this situation since we have a max of 4 oracles only, i think using a mapset is unnecessary. We also key the oracles based on config digest, which would be less meaningful in a mapset.
https://smartcontract-it.atlassian.net/browse/CCIP-2687
This PR in chainlink-ccip must be merged first: smartcontractkit/chainlink-ccip#285
Refactors the way we handle the launcher logic for ccip. Rather than managing state transitions in here, we just rely on the capability registry smart contract to manage the state.
What that means for us is that we simply need to read current state from the capability registry, and apply it by shutting down oracles that previously existed but no longer exist, and starting oracles that now exist but did not previously exist.
The code here is changed on two levels
-- DON management is handled in
launcher.go/processDiff, where we need to perform certain actions when a don is created, deleted, or updated-- This level manages the creation of Oracles, but not the starting and shutting down of oracles
-- Oracle management is handled really basically by
deployment.go/Transition.-- This level manages the
StartandStopof Oracle instances