Selected transaction setting is reset in bridge flow

[pavloburykh]

cc @vkjr

Steps:

1. Go to bridge flow
2. Change transaction fee on confirmation screen
3. Check if value is applied (not reset)

Actual result:

Fee value is reset to the default 'Fast' fee despite other fee type is selected

Status-debug-logs (4).zip

telegram-cloud-document-2-5309962995412002607.mp4

Additional Information

• Status version: PR Quick transaction settings #22019
• Operating System: Android, iOS

[vkjr]

Fix commited to #22019

[VolodLytvynenko]

hi @vkjr the issue is still reproducible in case ERC-20 assets are selected during the bridge

bridge5.mp4

logs:

https://drive.google.com/file/d/1DN30KJFPb6IKzGnWKe1M2b_VCANyQ1bC/view?usp=drive_link

[vkjr]

@VolodLytvynenko, thanks, checking

[vkjr]

@VolodLytvynenko, looks like it can be an issue on status-go side or not enough implementation on our side.

@saledjenic, when we receive route for bridge with erc-20, the field ApprovalRequired for that bridge is true. So when transaction identity built, it gets field isApprovalTx with same value.
When I send this transaction identity to SetFeeMode endpoint, I'm not getting error but also not receiving the fee mode change on next router update.
But if I manually set isApprovalTx to false then SetFeeMode works.

So I suppose that ApprovalRequired field in route should be fixed and set to false for Bridge.
@saledjenic What do you think?

[pavloburykh]

@vkjr @VolodLytvynenko let's leave this issue as a follow up, cause we do not want to block PR anymore.

[saledjenic]

@vkjr I don't fully understand what you've described.
Also, the tx settings part for the Bridge flow is not developed yet in the desktop app, but should be the same like we're doing for the send txs.

When I send this transaction identity to SetFeeMode endpoint, I'm not getting error

This is ok, you should get a new signal with the changes that you've set applied

but also not receiving the fee mode change on next router update.

This is odd. Do you have details of wallet.suggested.routes signal before and after applying the custom fee details?
Just for the context, one SetFeeMode should be done for approval tx, and another one for the bridge tx.

But if I manually set isApprovalTx to false then SetFeeMode works.

Not sure how you do that?

[vkjr]

@saledjenic.
1. I received a route (some fields omited):

{:Uuid "cfdfaa2c-8e82-4036-bcfd-1da4af22cc25",
  :Best
  [{:ApprovalTxNonce "0xa9",
    :AmountInLocked false,
    :SuggestedMinPriorityFee "0xf4240",
    :TxBonderFees "0x0",
    :ApprovalL1Fee "0x0",
    :AmountIn "0xde0b6b3a7640000",
    :SuggestedMaxPriorityFee "0x77359400",
    :RequiredNativeBalance 778776661362784,
    :ApprovalBaseFee "0x282dc80c",
    :TxTokenFees "-0x381ad7c66e205",
    :ApprovalGasAmount 46528,
    :ToToken nil,
    :SuggestedTxNonce "0xaa",
    :TxGasAmount 420000,
    :CurrentBaseFee "0x282dc80c",
    :TxNonce "0xaa",
    :AmountOut "0xdd2706ae4e4bf9c",
    :TxEstimatedTime 15,
    :SuggestedApprovalGasAmount 46528,
    :TxBaseFee "0x282dc80c",
    :ApprovalFee "0x46a3cd3f79c0",
!!  :TxGasFeeMode 1,
    :ApprovalContractAddress
    "0x3d4cc8a61c7528fd86c55cfe061a78dcba48edd1",
    :RouterInputParamsUuid "cfdfaa2c-8e82-4036-bcfd-1da4af22cc25",
    :TxL1Fee "0x0",
    :ApprovalMaxFeesPerGas "0x637f8b71",
    :ApprovalEstimatedTime 15,
    :TxMaxFeesPerGas "0x637f8b71",
    :TxPriorityFee "0x12ea2d1f",
    :UsedContractAddress "0x3d4cc8a61c7528fd86c55cfe061a78dcba48edd1",
    :RequiredTokenBalance 1000000000000000000,
    :SuggestedLevelsForMaxFeesPerGas
    {:mediumEstimatedTime 40,
     :highEstimatedTime 15,
     :medium "0x637f8b71",
     :lowPriority "0xf4240",
     :highPriority "0x77359400",
     :high "0xeff8ba5e",
     :low "0x283d0a4c",
     :lowEstimatedTime 0,
     :mediumPriority "0x12ea2d1f"},
!!  :ApprovalGasFeeMode 1,
    :ApprovalRequired true,
    :SuggestedTxGasAmount 420000,
    :TxTotalFee "0x2c44b12428860",
    :ProcessorName "Hop",
    :SubtractFees false,
    :ApprovalAmountRequired "0xde0b6b3a7640000",
    :ApprovalPriorityFee "0x12ea2d1f",
    :TxFee "0x27da745030ea0",
    :SuggestedApprovalTxNonce "0xa9"}],
  }

2. I set fee mode 0 by calling setFeeMode with following pathIdentity:

{:routerInputParamsUuid "cfdfaa2c-8e82-4036-bcfd-1da4af22cc25",
  :pathName "Hop", 
  :chainID 1, 
  :isApprovalTx true, 
  :communityID nil}

3. I received updated route:

{:in :handle-suggested-routes,
 :data
 {:Uuid "cfdfaa2c-8e82-4036-bcfd-1da4af22cc25",
  :Best
  [{:ApprovalTxNonce "0xa9",
   :AmountInLocked false,
   :SuggestedMinPriorityFee "0xf4240",
    :TxBonderFees "0x0",
   :ApprovalL1Fee "0x0",
   :AmountIn "0xde0b6b3a7640000",
   :SuggestedMaxPriorityFee "0x77359400",
   :RequiredNativeBalance 732517863949216,
   :ApprovalBaseFee "0x282dc80c",
   :TxTokenFees "-0x381ad7c66e205",
    :ApprovalGasAmount 46528,
   :ToToken nil,
   :SuggestedTxNonce "0xaa",
   :TxGasAmount 420000,
   :CurrentBaseFee "0x282dc80c",
   :TxNonce "0xaa",
   :AmountOut "0xdd2706ae4e4bf9c",
    :TxEstimatedTime 15, 
   :SuggestedApprovalGasAmount 46528,
   :TxBaseFee "0x282dc80c",
   :ApprovalFee "0x1c91560f7500",
!! :TxGasFeeMode 1,
   :ApprovalContractAddress
   "0x3d4cc8a61c7528fd86c55cfe061a78dcba48edd1",
   :RouterInputParamsUuid "cfdfaa2c-8e82-4036-bcfd-1da4af22cc25",
   :TxL1Fee "0x0",
   :ApprovalMaxFeesPerGas "0x283d0a4c",
   :ApprovalEstimatedTime 0,
    :TxMaxFeesPerGas "0x637f8b71",
   :TxPriorityFee "0x12ea2d1f",
   :UsedContractAddress "0x3d4cc8a61c7528fd86c55cfe061a78dcba48edd1",
   :RequiredTokenBalance 1000000000000000000,
   :SuggestedLevelsForMaxFeesPerGas
   {:mediumEstimatedTime 40,
   :highEstimatedTime 15,
   :medium "0x637f8b71",
   :lowPriority "0xf4240",
   :highPriority "0x77359400",
   :high "0xeff8ba5e",
   :low "0x283d0a4c",
   :lowEstimatedTime 0,
   :mediumPriority "0x12ea2d1f"},
!!  :ApprovalGasFeeMode 0,
   :ApprovalRequired true,
   :SuggestedTxGasAmount 420000,
   :TxTotalFee "0x29a389b1283a0",
   :ProcessorName "Hop",
   :SubtractFees false,
   :ApprovalAmountRequired "0xde0b6b3a7640000",
   :ApprovalPriorityFee "0xf4240",
   :TxFee "0x27da745030ea0",
    :SuggestedApprovalTxNonce "0xa9"}], }}

Just for the context, one SetFeeMode should be done for approval tx, and another one for the bridge tx.

Okay, now when you mentioned it I'm starting to understand that bridge has 2 fields that I need to change, right?
But inside our UI there is no separation to approval and bridge transaction, it is all performed in one go.

So If we don't want to create complexities for user, when ui setting changed, we need to call SetFeeMode 2 times.
First one with params:

{:routerInputParamsUuid "cfdfaa2c-8e82-4036-bcfd-1da4af22cc25",
  :pathName "Hop", 
  :chainID 1, 
! :isApprovalTx true, 
  :communityID nil}

And second with params:

{:routerInputParamsUuid "cfdfaa2c-8e82-4036-bcfd-1da4af22cc25",
  :pathName "Hop", 
  :chainID 1, 
! :isApprovalTx false, 
  :communityID nil}

@saledjenic, am I correct?

[saledjenic]

@vkjr basically yes, you're correct.

What we want is to align the process with what we have for swap. Also even it's technically possible at this moment to do the bridge tx via hop in a single go (without waiting for the approval tx to execute, but placing both txs (approval+bridge txs) at the same time), we cannot be sure if that will be the case later if we decide to add another bridge provider.

Also from the logical side of things, since the user is sending 2 txs in that flow, each of them has to be explicitly reviewed and the user should be able to customize parameters for each separately. That was discussed with @benjthayer and I guess it's communicated with @xAlisher.

That part is not covered yet in the desktop app, but will be when we finish the new bridge flow, @Khushboo-dev-cpp is working on that.

What I suggest to you is, to build the bridge flow in a way that the app iterates through all paths of the received route. For each path display review for the approval tx first if ApprovalRequired otherwise only review the bridge tx, let the user set custom parameters and every time parameters are confirmed, you can call SetFeeMode or SetCustomTxDetails, once the iteration is over call BuildTransactionsFromRoute.

[benjthayer]

Also from the logical side of things, since the user is sending 2 txs in that flow, each of them has to be explicitly reviewed and the user should be able to customize parameters for each separately. That was discussed with @benjthayer and I guess it's communicated with @xAlisher.

Yes! We'll need to design a variant of the signing dialog to allow the user to set gas paramaters for each individual transaction. @saledjenic when do you think designs for that will be needed? I'll try and balance it with the Trade Center work if urgent.

[saledjenic]

@benjthayer depends on @Khushboo-dev-cpp's progress. She is on the new bridge flow UI side.