Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the ✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
| /// and refund CCM metadata. | ||
| pub type VaultSwapParametersV0<RefundAddress> = | ||
| VaultSwapParameters<ChannelRefundParameters<RefundAddress, ()>>; | ||
| VaultSwapParameters<ChannelRefundParameters<RefundAddress, (), ()>>; |
There was a problem hiding this comment.
the () design has caused some tricky problems. I would strongly advise using a field with Option<> instead of this () pattern.
There was a problem hiding this comment.
I tried. Spent a day trying to change both of them to options and gave up in the end. Might re-visit it in another PR.
There was a problem hiding this comment.
yeah better to keep the previous one as is, and just add the new one as Option.
I considered changing this last time in the Solana refund parameter the refactor is too much
There was a problem hiding this comment.
yeah I will give that a try
| Ord, | ||
| )] | ||
| pub struct ChannelRefundParameters<A, CcmRefundDetails> { | ||
| pub struct ChannelRefundParameters<A, CcmRefundDetails, OracleSlippage> { |
There was a problem hiding this comment.
Same point as in the cf_parameter. If possible, avoid this and just use a field. Do we expect different types for the OracleSlippage?
There was a problem hiding this comment.
I think the problem is that we have a ton of different types that are derived from ChannelRefundParameters and if we create a separate "v2" type (which we would need to we can still decode the old type) without using generics, you will end up duplicating a lot of code. I'm also not a fan of using generics this way, but I would leave it to @j4m1ef0rd to investigate if there is a better way.
|
It might be a good idea to add an integration test as well, which can cover the entire workflow from requesting a swap all the way to egress. |
| Ord, | ||
| )] | ||
| pub struct ChannelRefundParameters<A, CcmRefundDetails> { | ||
| pub struct ChannelRefundParameters<A, CcmRefundDetails, OracleSlippage> { |
There was a problem hiding this comment.
I think the problem is that we have a ton of different types that are derived from ChannelRefundParameters and if we create a separate "v2" type (which we would need to we can still decode the old type) without using generics, you will end up duplicating a lot of code. I'm also not a fan of using generics this way, but I would leave it to @j4m1ef0rd to investigate if there is a better way.
afccdff to
610c911
Compare
610c911 to
1f7c917
Compare
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! |
| pub affiliates: BoundedVec<AffiliateAndFee, ConstU32<MAX_AFFILIATES>>, | ||
| } | ||
|
|
||
| impl From<BtcCfParametersV0> for BtcCfParameters { |
There was a problem hiding this comment.
Nit: In order to keep it consistent with the other chain's cf_parameters I'd suggest renaming BtcCfParameters to BtcCfParametersV1.
| VaultSwapParameters<ChannelRefundParameters<RefundAddress, ()>>; | ||
| VaultSwapParameters<ChannelRefundParametersV0<RefundAddress>>; | ||
|
|
||
| /// New version of `VaultSwapParameters` that includes refund CCM metadata. |
There was a problem hiding this comment.
| /// New version of `VaultSwapParameters` that includes refund CCM metadata. | |
| /// New version of `VaultSwapParameters` includes refund CCM and oracle price slippage. |
|
|
||
| #[cfg(test)] | ||
| pub fn build_and_encode_v0_cf_parameters<RefundAddress: Encode>( | ||
| refund_parameters: crate::ChannelRefundParametersV0<RefundAddress>, /* crate::ChannelRefundParametersUncheckedV0<RefundAddress>, */ |
There was a problem hiding this comment.
Remove commented code.
| ); | ||
|
|
||
| let min_output = | ||
| output_amount_ceil(swap.swap.input_amount.into(), min_price) |
There was a problem hiding this comment.
Any particular reason why we use output_amount_ceil instead of output_amount_floor? I don't think it matters here but normally the rounding tends to be done in "favor" of the protocol per say, just to cover any edge cases.
Since it's not AMM logic that's almost certainly not relevant though, so it's just curiosity.
There was a problem hiding this comment.
No particular reason. Like you said, this shouldn't matter, but I'm not against changing this to output_amount_floor.
| gas_budget: fillOrKillParams?.refundCcmMetadata.gasBudget, | ||
| ccm_additional_data: fillOrKillParams?.refundCcmMetadata.ccmAdditionalData, | ||
| }, | ||
| max_oracle_price_slippage: undefined, // TODO: update FillOrKillParamsX128 with max_oracle_price_slippage |
There was a problem hiding this comment.
Right now the bouncer is using "@chainflip/cli": "1.9.0-assethub.0-ccm-refunds", which is a little patch I made so FillOrKillParamsX128 contains the refund_ccm_metadata. Then the web team will add that to the 1.11 SDK.
We can add max_oracle_price_slippage in that same branch, as it's a little patch anyway, so we can use this in the bouncer. @j4m1ef0rd lmk if you'd want me to help out with that.
Then I think we should have a oracle swap FoK test in tests/fill_or_kill.ts the same way that we have it for regular and CCM refunds.
There was a problem hiding this comment.
I made the changes to your branch but I dont have permissions to push it. So I will do this bouncer stuff in another PR so we can merge this now.
a1c131d to
93b5f8b
Compare
Pull Request
Closes: PRO-2331
Checklist
Please conduct a thorough self-review before opening the PR.
Summary
TODO: Need some input from @dandanlen
request_swap_deposit_address_with_affiliatesandrequest_swap_deposit_addressextrinsics.cf_request_swap_parameter_encoding. This will most likely need a new RPC, can be done in another PR.schedule_swapandlp_schedule_swap(aka internal swap). should we make another extrinsic instead?