Skip to content
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

dApp - quick pay delay after blockchain interaction #3078

Closed
weilbith opened this issue Mar 21, 2022 · 0 comments · Fixed by #3079
Closed

dApp - quick pay delay after blockchain interaction #3078

weilbith opened this issue Mar 21, 2022 · 0 comments · Fixed by #3079

Comments

@weilbith
Copy link
Contributor

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

  • [ ]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant