messages lost due to e2e encryption
when using end to end encryption, messages got lost and these exceptions showed up:
for lack of direct access to the other end, i can't give details on what it looked like there.
e2e authenticity was established, both ends use gajim-0.16beta
Steps to reproduce
can't tell, just happens. the first exception potentially came up after i disabled e2e for the main account.
OS version: Debian GNU/Linux sid/experimental
GTK version: 2.24.8-2
PyGTK version: 2.24.0-2
i disabled e2e using the advanced options (enable_esessions set to deactivated for that account). the chat stayed encrypted telling from the icon; the icon went away when i closed and opened the chat.
i'm going to re-enable it for partners i can afford to lose messages with and with whom i can debug it.
in the meantime, i had a quick look at the code in connection_handlers_events; besides HelperEvent being old-style object (which, as far as i am informed, is calling for trouble), i found that thw show_in_roster attribute gets set unconditionally in generate(), while msg_id would have to be assigned from outside (not accessed in DecryptedMessageReceivedEvent's functions). we'd need to find out where those incompletely instanciated objects come from.
what do you mean by old-style object?
msg_id is set in session.py. And as all message should be in a session, all messages should go through the decrypted handler in session.py. It seems (if the tb occures) that some messages don't have a session, that's what I'd like to understand.
Having the XML that causes this would help, but as it's hard to reproduce ...
thanks, trying it out now.
to finish up on the old-style object issue: since around python 2.3, you create classes by
even if you don't inherit from anything particular (old style classes are still there for compatibility reasons). i don't expect problems to show up here 'cause the objects won't be mixed with exceptions or integers, but it's generally bad practice to still use them these days.