-
Notifications
You must be signed in to change notification settings - Fork 427
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
refactor: simplify warp route deployment and update logic #5358
base: main
Are you sure you want to change the base?
Conversation
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #5358 +/- ##
=======================================
Coverage 77.53% 77.53%
=======================================
Files 103 103
Lines 2110 2110
Branches 190 190
=======================================
Hits 1636 1636
Misses 453 453
Partials 21 21
|
df66840
to
7f86337
Compare
typescript/cli/src/deploy/warp.ts
Outdated
if (transactions.length == 0) | ||
return logGreen(`Warp config is the same as target. No updates needed.`); | ||
|
||
await submitWarpApplyTransactions(params, groupBy(transactions, 'chainId')); | ||
} | ||
|
||
async function extendWarpRoute( | ||
async function deployNewWarpRoutes( |
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.
Why the rename here?
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.
as I changed the functionality I renamed it, now that reverted that change no need to rename so reverted
typescript/cli/src/deploy/warp.ts
Outdated
params: WarpApplyParams, | ||
apiKeys: ChainMap<string>, | ||
warpDeployConfig: WarpRouteDeployConfig, | ||
warpCoreConfigByChain: ChainMap<WarpCoreConfig['tokens'][number]>, | ||
) { | ||
): Promise< | ||
| { |
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.
Would maybe be useful to add comments here for what the return values are?
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.
removed return values
typescript/cli/src/deploy/warp.ts
Outdated
warpCoreConfigByChain, | ||
); | ||
|
||
if (deployResult) { |
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.
Why did you move this out of extendWarpRoute
and into this function?
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 just wanted to make it pure function, but based on current state of warp.ts
it was not a good idea, moved it into extendWarpRoute again
typescript/cli/src/deploy/warp.ts
Outdated
destinationGas, | ||
); | ||
|
||
config.remoteRouters = remoteRouters; |
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.
Is this mutative behavior necessary? I was hoping that we could do something like
const expandedConfig = { remoteRouters, destinationGas, ...config }
That way you allow warp apply that explicitly specifies routers and destination gas to just use those values, but if they don't (which we expect most, if not all warp routes to do), they get the fully-enrolled behavior
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.
In that case if you do warp read
before your warp apply
, apply wont fix unenrolled routes as read wrote the current state on warp-deployment file.
Is this ok?
so if you want to fix your broken routes you should not have any remoteRoutes
and destinationGas
properties for your route.
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.
or maybe we can define --full-enrollment
or something like this later on separated PR.
[to ignore warp deployment file and fully enroll and update destination gas on all routers]
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.
Clarified this on the ticket now as well, but basically I want this behavior:
c) standardize the remoteRouters and destinationGas mapping behavior to:
i. if the passed in config to warp apply
contains the remoteRouters and destinationGas mapping use that
ii. it eh passed in config does not contain those mappings, assume fully connected routers and use the gas value of each chain to construct the destinationGas mapping
Does that help clarify the intended behavior?
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.
Also would like to see test cases for this behavior as well
@@ -627,17 +703,36 @@ async function updateExistingWarpRoute( | |||
); | |||
const transactions: AnnotatedEV5Transaction[] = []; | |||
|
|||
// Get all deployed router addresses |
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 generally view these kind of transforms as "config expansion", i.e. really WarpDeployConfig
is kind of a subset of HypTokenRouterConfig
and so things like expanding remoteRouters and destinationGas i would just put into a separate function (like populateDestinationGas
already is. i.e. ideally something like
const expandedConfig = crossProduct({ remoteRouters: await getRouters(), destinationGas: await destinationGas()})
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.
make sense
@@ -371,4 +371,114 @@ describe('hyperlane warp apply e2e tests', async function () { | |||
expect(Object.keys(destinationGas_3)).to.include(chain2Id); | |||
expect(destinationGas_3[chain2Id]).to.equal('7777'); | |||
}); | |||
|
|||
it('should recover from manual router unenrollment', async () => { |
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.
Can you add a bit more context here on what you believe the test is doing? I'm actually not sure I agree with the premise of the test 😅
@@ -371,4 +371,114 @@ describe('hyperlane warp apply e2e tests', async function () { | |||
expect(Object.keys(destinationGas_3)).to.include(chain2Id); | |||
expect(destinationGas_3[chain2Id]).to.equal('7777'); | |||
}); | |||
|
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.
A test I very much would like to add is the one from the issue. I.e. a warp route was extended, but the update txs were not applied, and then running warp apply with the same deploy config and updated warp core config results in the expected outcome
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.
Yes this makes sense, I already tested it manually, will add e2e test for this. this will require to export extendWarpModule function
Description
Drive-by changes
Related issues
#5317
Backward compatibility
Testing