Reliable Reconnection

[lgrahl]

This is an umbrella issue that tracks known issues related to reconnection attempts which need resolving before we can release the reconnect overhaul code introduced by #792. The rationale here is that the multiple pushes trigger race conditions in both the iOS and the Android app (which is good because at least we can now reproduce them better).

This issue is not intended for discussion. If you encounter further issues you suspect are not listed here or you have new insights, please file a new issue.

Threema Web

• Signaling: Subsequent responder handshakes trigger a protocol error #799: Investigate why it causes these UI issues (PR: Handle signaling connection state changes before handover #803)
• Delayed dispatching of the connection state results in race conditions #812, Force reloading when signalling connection is lost #818: Issues with the state machine (also, orange bar phenomenon when there's no internet connection).
• Re-apply multi-push solution

SaltyRTC Server

• Fix path duplication saltyrtc/saltyrtc-server-python#114: Fix path duplication
• Deploy

SaltyRTC Client JS

• Subsequent responder handshakes trigger a protocol error saltyrtc/saltyrtc-client-js#114: Handle multiple responders.
• Release and integrate into Threema Web.

SaltyRTC Client Java

• Handshake attempts after 'task' state trigger a protocol error saltyrtc/saltyrtc-client-java#102: Potential protocol error during handshake.
• Wrong send-error validation saltyrtc/saltyrtc-client-java#99: Potential protocol errors when relaying failed.
• Release and integrate into Android App.

SaltyRTC Client Rust

• Ignore an unknown responder saltyrtc/saltyrtc-client-rs#59: Ignore unknown responder.
• Handle new-initiator/new-responder correctly saltyrtc/saltyrtc-client-rs#61: Handle multiple responders.
• Release and integrate into iOS App.

Android App

• Must not establish multiple SaltyRTC connections of the same session (internal: ANDR-909).
• Must not wait until a previous SaltyRTC connection has been stopped / a timer fired when the affiliation id of the push (wca) is different. It should discard the connection and restart the web client session immediately (internal: ANDR-908).
• Must ignore pushes with the same affiliation id (wca) when it is already connected or currently establishing a connection with that id (internal: ANDR-909).
• Must not ignore pending wakeups (internal: ANDR-914).
• Wakeup must work properly (state handling refactoring).
• Release.

iOS App

• Must not wait until a previous SaltyRTC connection has been stopped / a timer fired when the affiliation id of the push (wca) is different. It should discard the connection and restart the web client session immediately (internal: IOS-751).
• Must ignore pushes with the same affiliation id (wca) when it is already connected or currently establishing a connection with that id (internal: IOS-751).
• Release.

[lgrahl]

Just wanted to let everyone know that we've resolved a couple of race conditions in the Android app that resulted in reconnect attempts being ignored. Should be in the next release.