Dowloaded/decrypted messages unavailable in UI

[heartsucker]

After signing in to the app, rapidly changing the selected conversation prevents downloaded/decrypted messages from displaying

STR

1. Boot dev container
2. Boot app
3. Sign in
4. Immediately click Source A
5. Immediately click Source B

Expected

Source A and Source B should show the content of their messages.

Actual

Source A and Source B show Message not yet available until a sync occurs (manual, timed)

Notes

This is likely related to #352 and was likely caused by #345. I could be wrong. I think the underlying cause is that the decryption signal never hits the widget because it is garbage collected.

[sssoleileraaa]

Let's focus on the underlying cause. I think you're right about the decryption signal sometimes not making it to the widget, which will require more investigation.

More details

If you run through the STR above a handful of times, you will see that sometimes source messages load, and sometimes they don't, and sometimes only a couple replies load, and sometimes only a couple messages load. And this varies across sources.

All of this is "fixed" when you manually refresh.

[sssoleileraaa]

More troubleshooting:

Sometimes, messages in the conversation view will return back to "Message not yet available" after they have already appeared in plaintext.

STR:

1. start the client
2. click on a source, see messages in plaintext
3. click on a different source and go back to the previous source you had selected, see messages appear as "Message not yet available"

[eloquence]

For the current (5/30-6/12) sprint, we've committed to a 4 hour time-boxed attempt to resolve; additional issues may be created as a result of that investigation.

[sssoleileraaa]

Seeing:

.virtualenvs/securedrop-client-CFeBqBy8/lib/python3.5/site-packages/sqlalchemy/orm/persistence.py:1347: SAWarning: DELETE statement on table 'replies' expected to delete 5 row(s); 4 were matched.  Please set confirm_deleted_rows=False within the mapper configuration to prevent this warning.
  % (table.description, expected, rows_matched)

when restarting both the server and client after there has been a local reply

[redshiftzero]

ah, that issue seems to be the same as #360