Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
👋 PabloMansanet, thanks for creating this pull request! To help reviewers, please consider creating future PRs as drafts first. This allows you to self-review and make any final changes before notifying the team. Once you're ready, you can mark it as "Ready for review" to request feedback. Thanks! |
Coverage Report |
andrevmatos
left a comment
There was a problem hiding this comment.
Proposed some changes, to allow the existing implementation of getLaneFeatures to use only existing methods (instead of hitting the contracts directly).
With those changes, I think we can move this implementation to the concrete generic implementation inside Chain.getLaneFeatures, and will serve everyone (i.e. once they start supporting v2, it is).
| const tokenPool = (await onRampContract.getPoolBySourceToken( | ||
| opts.destChainSelector, | ||
| opts.token, | ||
| )) as string |
There was a problem hiding this comment.
Can we use the existing method instead of hitting the contract directly? This may make it more generic in the future
| const tokenPool = (await onRampContract.getPoolBySourceToken( | |
| opts.destChainSelector, | |
| opts.token, | |
| )) as string | |
| const { tokenPool } = await this.getRegistryTokenConfig( | |
| await this.getTokenAdminRegistryFor(onRamp), | |
| opts.token, | |
| ) |
There was a problem hiding this comment.
This does a lot more thoug, right? The registry path does typeAndVersion (line 997) + getStaticConfig (line 1017) + getTokenConfig (line 1434) = 3 calls, vs the current single getPoolBySourceToken call.
There was a problem hiding this comment.
As per our chat: let's approach in a followup
| const poolContract = new Contract( | ||
| tokenPool, | ||
| interfaces.TokenPool_v2_0, | ||
| this.provider, | ||
| ) as unknown as TypedContract<typeof TokenPool_2_0_ABI> | ||
| const minBlockConfirmations = Number(await poolContract.getMinBlockConfirmations()) |
There was a problem hiding this comment.
Just for consistency, can we add minBlockConfirmations? as part of the EVM-specific return type of getTokenPoolConfig method, return it in there if pool is >=v2, and then use that method here?
There was a problem hiding this comment.
Hmm I'm not sure about this one, I think it confuses things a bit for the sake of consistency. minBlockConfirmations is its own method in the ABI and it's not marked as "config" anywhere. Just like it's lane features and not lane config, I don't think this value should come from getTokenPoolConfig
There was a problem hiding this comment.
As per our chat: let's approach in a followup
There was a problem hiding this comment.
Ok, please, just don't forget it 😅
| const poolContract = new Contract( | ||
| tokenPool, | ||
| interfaces.TokenPool_v2_0, | ||
| this.provider, | ||
| ) as unknown as TypedContract<typeof TokenPool_2_0_ABI> | ||
| const minBlockConfirmations = Number(await poolContract.getMinBlockConfirmations()) |
There was a problem hiding this comment.
Ok, please, just don't forget it 😅
Fully fork tested, with a caveat:
There was a recent rename of the token pool method
getMinBlockConfirmation()togetMinBlockConfirmations()(note the plural). To keep with the patterns in this codebase, we only generate our token pool ABI based on the latest upstream code, so we only check for the existence of the plural.Current staging deployments are mostly on the older naming, with only the Lombard LBTC pool (as far as I know) using the plural form. This means our fork tests can only check the Lombard case (FTF disabled). As soon as more pools migrate, we'll be able to add fork tests that verify FTF support in other pools.