You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the compatibility for Arbitrum, we also got zero confirmation blocks. In the scenario player runs we have seen that it can sometimes lead to issues when interacting with a channel that was just created/modified. Due to the zero confirmation blocks, the active node who modified the channels state immediately continues without a break. In result it leads to an unsynced partner node who has not yet seen the new channel/new deposit and will deny/error on the sent message. To prevent this issue, the scenarios received a couple of short delays after such a blockchain interaction.
For the "normal" user flow with open a channel manually and then continue with a transfer, this is not an issue for the dApp. But for the quick-pay feature we also observed this problem. Due to the automated nature of this feature, it will also immediately continue to act on the channel that just got opened or deposited to. The same solution approach as described above should be good enough. On non Arbitrum network the extra short delay isn't much of a factor. And for Arbitrum it is necessary to prevent such unsynchronized issues too often where the quick-pay transfer will completely fail.
Acceptance criteria
Tasks
[ ]
The text was updated successfully, but these errors were encountered:
Description
With the compatibility for Arbitrum, we also got zero confirmation blocks. In the scenario player runs we have seen that it can sometimes lead to issues when interacting with a channel that was just created/modified. Due to the zero confirmation blocks, the active node who modified the channels state immediately continues without a break. In result it leads to an unsynced partner node who has not yet seen the new channel/new deposit and will deny/error on the sent message. To prevent this issue, the scenarios received a couple of short delays after such a blockchain interaction.
For the "normal" user flow with open a channel manually and then continue with a transfer, this is not an issue for the dApp. But for the quick-pay feature we also observed this problem. Due to the automated nature of this feature, it will also immediately continue to act on the channel that just got opened or deposited to. The same solution approach as described above should be good enough. On non Arbitrum network the extra short delay isn't much of a factor. And for Arbitrum it is necessary to prevent such unsynchronized issues too often where the quick-pay transfer will completely fail.
Acceptance criteria
Tasks
The text was updated successfully, but these errors were encountered: