This fixes an edge case I ran into involving logic where the client automatically handles reconnecting and resuming the stream.
I needed a way to listen for a stanza or event that indicates the stream is fully restored and can be used to send messages again (for example to try resending messages that were sent while offline)
the <resumed> stanza received from the server after a <resume> stanza is sent from the client seemed like a good candidate for this, however listening for that event and assuming the JID was available right away was where I was getting buggy behavior.
This change makes sure the JID is restored before sending the <resume> stanza but also nulls it out if that fails for whatever reason
This fixes an edge case I ran into involving logic where the client automatically handles reconnecting and resuming the stream.
I needed a way to listen for a stanza or event that indicates the stream is fully restored and can be used to send messages again (for example to try resending messages that were sent while offline)
the
<resumed>stanza received from the server after a<resume>stanza is sent from the client seemed like a good candidate for this, however listening for that event and assuming the JID was available right away was where I was getting buggy behavior.This change makes sure the JID is restored before sending the
<resume>stanza but also nulls it out if that fails for whatever reason