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

Corrupted application state from stale connections #339

snez opened this Issue Sep 16, 2012 · 7 comments


None yet
5 participants

snez commented Sep 16, 2012

This is a cross-post from

How to reproduce the issue:

  1. Open the same app (from a remote server) in two browser windows.
  2. Turn off wi-fi (or 3g) - connection becomes stale because it was not closed from the remote server.
  3. Perform a write operation in the first tab (the second tab will of course not update reactively).
  4. Turn on wi-fi.
  5. Perform a second write in the first tab (the second tab will now update reactively)
  6. So the first tab is now in a corrupted state. The first write will never sync to the server, and if the page reloads, that change will be permanently lost.

Not sure if Meteor can already handle this scenario, or should this be a "data validation" feature request?


This comment has been minimized.


debergalis commented Sep 17, 2012

I couldn't reproduce this. Could you report on what value "Meteor.status().status" has at each step in the sequence?


This comment has been minimized.

snez commented Sep 18, 2012

It stays as "connected" as well. I am testing this on (which is Meteor 0.4) - I go there, turn off wi-fi (on OS X Lion), then check Meteor.status().status from the browser console.


This comment has been minimized.


n1mmy commented Sep 18, 2012

I was able to reproduce on 0.4.0 and on devel using the todos app. This looks like a regression, meteor is supposed to re-transmit all the updates that were done while disconnected an re-sync the state.


This comment has been minimized.


avital commented Sep 19, 2012

We also repro'd this using todos. It seems that one of the tabs thinks it's sent methods to the server when in fact it hasn't. Method replay on reconnect should handle this correctly but it apparently doesn't.


This comment has been minimized.

snez commented Sep 23, 2012

This may need some work on a low level, a ping packet should be periodically sent to the server through the open websocket, which in turn should respond with a pong. If a pong is not received within say 1 minute, any data that has been sent to the server since the last pong should be validated with the server..


This comment has been minimized.


glasser commented Sep 23, 2012

The sockjs implementations do do some sort of heartbeat already. But they may not be working properly.


This comment has been minimized.

snez commented Sep 23, 2012

I think they do work because after a while Meteor.status().connected does become false, presumably as a result of the sockjs heartbeat implementation. However as a solution it may still not be robust enough because data transmitted while the connection was stale may have been lost and neither the server nor the client will check that.

I would think that a robust solution would be to perform some sort of 2 way handshake when sending data, i.e. send 1k of data from the client and ask the server if it received that data - then if the server replies with 1024 bytes received, then the transmission has been validated..

@ghost ghost assigned avital Sep 27, 2012

@avital avital closed this in 3e2de50 Nov 15, 2012

n1mmy added a commit that referenced this issue Nov 16, 2012

Update sockjs to 0.3.4. This removes the meteor patch from #339, but …
…preserves the patch to do http->https on IE.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment