-
Notifications
You must be signed in to change notification settings - Fork 10
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
Device linking reliability #100
Comments
As a first step on this issue - we should deploy and test with versions of WAT etc and webnative 0.34, not the currently deployed version. No use in trying to fix a bug that's already fixed. |
Andy fixed this issue in the 0.35 branch |
I've attempted a reproduction in https://github.com/fission-codes/aol-demo/tree/upgrade-webnative-0.35.0 to gather more information from a second app. The issue was not reproducible on a couple of attempts linking between desktop browsers including:
There were however issues linking from Desktop Firefox to Chrome on iOS. The symptoms are a bit different. Using These messages are logged here: https://github.com/fission-codes/webnative/blob/3bd09cdd70d24d6df32cf9630d6565b9b2beff5b/src/components/auth/channel.ts#L53-L87 It seems like this should make more than just two attempts. |
The Chrome on iOS and Safari iOS issues with retries described above are fixed in oddsdk/ts-odd#446. |
I've done some testing of device linking and it is uh reliably unreliable; in numerous tests with various browsers / OS, device linking stalls:
What happens:
When the browsers are in this state, I have seen it start working after refreshing browser A, but this is not reliable.
In a successful device linking session I see WS messages being sent from browser A in response to browser B, but this never happens on the first attempt to link.
The text was updated successfully, but these errors were encountered: