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 edited by helfer

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?


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

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.

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.

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.

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..

glasser commented Sep 23, 2012

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

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..

@avital avital was assigned Sep 27, 2012
@avital avital closed this in 3e2de50 Nov 15, 2012
@n1mmy n1mmy added a commit that referenced this issue Nov 16, 2012
@n1mmy n1mmy Update sockjs to 0.3.4. This removes the meteor patch from #339, but …
…preserves the patch to do http->https on IE.
@avital avital was unassigned by helfer May 3, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment