-
Notifications
You must be signed in to change notification settings - Fork 184
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
Signaling messages lost in the social provider #739
Comments
localGrantsAccessToRemote is a getter for localGrantsAccessToRemote_, i believe. |
I can't reproduce this. Did you reload the app or sign out/in while you were doing it? |
Just tried, also not able to replicate |
Hrm... wonder if it was related to having multiple instances online... I'll do more debugging and see how to reproduce it. Thanks for trying. |
This seems more like xmpp failure and could be related to #725. |
w.r.t. localGrantsAccessToRemote and localGrantsAccessToRemote_: in the code sample, they are both boolean params of the UI update message. This is definitely not right. :) |
OK, I couldn't reproduce the exact same thing, but what is happening pretty consistently (and looks like it could easily be the same underlying issue) is that some of the messages sent via XMPP do not get to the other side. e.g. exert from end of getter log:
exert from end of giver log:
|
Changing this from P0 to P1, since most of us are able to use uProxy |
Closing this issue - we have not been able to replicate this recently, but believe it may have been fixed by freedomjs/freedom-social-xmpp#80 (fix bug where all messages within the same "batch" were being sent to the same destination). Also we've added integration tests (#753) to help us detect if things break in the future, and fixed our error handling code (freedomjs/freedom-social-xmpp#77) so that we properly print out error messages. |
Version: uProxy from dev ( commit 99cc2d1 , as of Tue Dec 23 11:10:49 2014 -0500 ), tested on Chrome Canary.
Steps:
Expected:
Actually see:
Additional Details:
From looking at the logs, it doesn't look like A ever got B's offer message.
Also, From looing at B, it looks like we may have broken some variable namings... I see this in the logs:
In particular, notice the suspicious fact that we have both the key
localGrantsAccessToRemote_
and the keylocalGrantsAccessToRemote
in the consent state. Also:localRequestsAccessFromRemote_
andlocalRequestsAccessFromRemote
.The text was updated successfully, but these errors were encountered: