As it turns out, some of these tests used message IDs 1 and 2, which
Hamlet didn't even necessarily receive as the messages to update --
which meant that they previously updated 0 messages and returned
success. So those tests started failing when I added a check for not
updating anything in the update_message_flags backend -- and this
commit fixes the tests to actually update a nonempty set of messages.
(imported from commit 9034b415d4862216a266416a8e509d987050ffd7)
To apply this change, we must not only do a puppet apply, but also
restart rabbitmq and epmd. Rabbitmq is easy to restart, but epmd is
a little more annoying. epmd is run as a side effect of starting up
rabbitmq-server, but is not stopped when rabbitmq-server is stopped.
Therefore, the correct procedure is to stop rabbitmq-server, kill
epmd (by running `epmd -kill`), and then start rabbitmq-server again.
(imported from commit a651e5363a8b9a04b713c31baef379c566d5dbfc)
This has a small bug where we don't actually filter the message out of
the home view; fixing that requires adding an index on the "flags"
field of UserMessage.
(imported from commit 492c99d0a8e87b253e577be6564bec12099bd8e9)
When we add starring of historical messages, they'll get added to the
home view (since we don't filter them out), which isn't a big deal --
but we don't want to make an inaccurate claim that the user subscribed
to this stream and then unsubscribed.
This should most properly be handled by filtering server-side, but at
the moment our lack of an index on UserMessage.flags makes that
impractical from a performance perspective.
(imported from commit 00751a5f9fc20e9da5c09914c11d1579f9e7398e)
There seems to be some sort of bug involving PhantomJS and XHR
streaming messages. When successive pages are loaded that use XHR
streaming, PhantomJS seems to think the second one never finishes
loading and therefore hangs.
(imported from commit db93b4cab816f1fdc3f3f543c9394b1cba8abedb)
We really should be setting a variable in Javascript to indicate that
we've finished loading, but this hasn't bitten us yet.
(imported from commit ee1f7c76d9f3c482561cc5c44b81537c7e9636be)
Because our authentication system reads cookies from the initial
connection attempt, several SockJS transports can't be used.
(imported from commit 34b9571225d39072985b8223fb12c43c7235841f)
New dependency: sockjs-tornado
One known limitation is that we don't clean up sessions for
non-websockets transports. This is a bug in Tornado so I'm going to
look at upgrading us to the latest version:
https://github.com/mrjoes/sockjs-tornado/issues/47
(imported from commit 31cdb7596dd5ee094ab006c31757db17dca8899b)
We want to deprecate reload_subscriptions(), which was kind
of a big hammer to use when only a single stream is being
renamed. Now we call stream_list.rename_stream() to update
the sidebar.
(imported from commit a77d09c0433d9b605b7baa7d7c61183bc8c37ba9)
For a large domain like HS, we were pulling back about 100k of
text with subscriber emails when we opened the Streams page.
This was unnecessary, as the subscribers aren't shown until
you expand the stream, and there's already an AJAX call.
(imported from commit 69b83d769030d87318acefc364ac6ff3a2ec3605)
The gather_subscriptions_helper() does a separate query to
get emails from user_ids, and it returns an email_dict to its
caller.
This may seem like a step backward, since gather_subscriptions()
now needs to do an additional query, but there is some benefit
in passing fewer redundant emails over the wire from the DB.
The real payoff, though, will come in subsequent commits, where
we will reduce the amount of data going over the wire to the browser,
which will benefit users with slow connections.
(imported from commit bf1cc5828a4c5f68cafd052ea29a177837970206)
I am about to change the behavior of the internal API, and it's really more
important to have test coverage on the external API anyway.
(imported from commit 8a0723cbcb4ac1819a63397584aa40e69ceb827d)
Zev Benjamin
Waseem Daher
Leo Franchi
Tim Abbott
Tim Abbott
Tim Abbott
Allen Rabinovich
Steve Howell