Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reconnect overhaul #792

Merged
merged 13 commits into from May 9, 2019

Conversation

Projects
None yet
4 participants
@lgrahl
Copy link
Contributor

commented Apr 29, 2019

Push Session (aka Continuous Pushes)

Add a push session instance will send pushes continuously until an undefined goal has been achieved which needs to call the .done method to stop pushes.

The push session will stop and reject the returned promise in case the push relay determined a client error (e.g. an invalid push token). In any other case, it will continue sending pushes. Thus, it is crucial to call .done eventually!

With default settings, the push session will send a push in the following intervals: 0s, 2s, 4s, 8s, 16s, 30s (maximum), 30s, ...
The first push will use a TTL of 0, the second push a TTL of 15s, and all subsequent pushes will use a TTL of 90s.

The default settings intend to wake up the app immediately by the first push which uses a TTL of 0, indicating the push server to deliver now or never. The mid TTL tries to work around potential issues with FCM clients misinterpreting the TTL as don't need to dispatch until expired. And the TTL of 90s acts as a last resort mechanism to wake up the app eventually.

Device Unreachable Dialog

Instead of redirecting to the welcome page (Android) or doing nothing and letting the web client remain in a limbo state (iOS), the push session will retry waking the device three times. If that is unsuccessful, it will show a new dialog that allows to either retry or reload page. This dialog will disappear automatically once a connection to the device has been established.

Fast Session Recovery

When the connection to the app is already lost but there was no explicit closure, we previously had to wait until the SaltyRTC server or the underlying transport recognised that the connection has been lost.

With this change, we request a connectionAck and send a push after 3 seconds of silence (no incoming chunks). This has a cooldown phase of 10 seconds.

Note: This only affects iOS at the moment.

To Do

  • Investigate if there are other timers messing with the connection (e.g. iOS)
  • Optionally reject after N retries
  • On welcome, stop after N retries but don't show a dialog or fail the session
  • On messenger, stop after N retries and show an alert dialog which allows to retry. The dialog should automatically close if the connection resumes in the background.
    • Link to Push FAQ should automatically redirect to the appropriate language (@sillych)

Resolves #354

@lgrahl lgrahl requested a review from dbrgn Apr 29, 2019

@lgrahl

This comment was marked as resolved.

Copy link
Contributor Author

commented Apr 30, 2019

Note: On an unrecoverable push error, this shows a generic protocol error dialog. We may want to change that to something like: Unable to wake up device, retry?

@lgrahl lgrahl force-pushed the push-overhaul branch 5 times, most recently from 330d3f7 to a708140 Apr 30, 2019

@lgrahl lgrahl changed the title Push overhaul Reconnect overhaul May 2, 2019

@lgrahl lgrahl force-pushed the push-overhaul branch from a708140 to 85953d1 May 2, 2019

@dbrgn
Copy link
Contributor

left a comment

🎉 This is great.

Show resolved Hide resolved src/services/push.ts Outdated
Show resolved Hide resolved src/services/push.ts
Show resolved Hide resolved src/services/push.ts Outdated
Show resolved Hide resolved public/i18n/de.json Outdated
Show resolved Hide resolved public/i18n/en.json
Show resolved Hide resolved src/services/push.ts
Show resolved Hide resolved src/services/push.ts Outdated
Show resolved Hide resolved src/services/state.ts
Show resolved Hide resolved src/services/state.ts Outdated
Show resolved Hide resolved src/services/webclient.ts

@lgrahl lgrahl force-pushed the push-overhaul branch 3 times, most recently from 3ccd7a8 to 9faa97c May 6, 2019

@dbrgn

This comment was marked as resolved.

Copy link
Contributor

commented May 6, 2019

When closing a session by disabling Threema Web in the app, the "please start your session" screen is shown, instead of the welcome screen.

screenshot

@lgrahl lgrahl force-pushed the push-overhaul branch from 370453b to 75ed742 May 7, 2019

@lgrahl

This comment has been minimized.

Copy link
Contributor Author

commented May 7, 2019

⬆️ Fixed.

@lgrahl lgrahl requested a review from dbrgn May 8, 2019

@dbrgn

dbrgn approved these changes May 8, 2019

lgrahl added some commits Apr 25, 2019

Refactor PushService for more coordinated retrying
The PushService can spawn a Push instance which...

- Retransmits the Push until an undefined goal has been achieved
- Applies a TTL to the push message
- Collapses push messages by applying a collapse key
Add "device unreachable" dialog and improve welcome page
The texts of the welcome page have been updated and are being mostly
reused for the "device unreachable" dialog.

Further changes:

- Removed fixed height requirement for the welcome page.
- Removed dead code in welcome page CSS
Use "device unreachable" dialog for soft-reconnect on Android
Remove all the timeout/retry logic for reconnecting Android
Use part of the session hash as collapse key
This allows the push server to collapse all pushes from the same
session since the device is only interested in the most recent push.
Apply "device unreachable" dialog to reconnecting logic
An attempt to re-establish a connection may fail for different
reasons than pushes. For example, WebRTC could be blocked by a plugin
or the WebSocket connection fails.

If the connection cannot be established after 3 tries, the "device
unreachable" dialog will be shown.
Add affiliation to PushService
This allows the app to detect whether consecutive pushes are
referring to the same session connection attempt.
Implement fast session recovery
When the connection to the app is already lost but there was no explicit
closure, we previously had to wait until the SaltyRTC server or the
underlying transport recognised that the connection has been lost.

With this change, we request a connectionAck and send a push after 3
seconds of silence (no incoming chunks). This has a cooldown phase of
10 seconds.

@lgrahl lgrahl force-pushed the push-overhaul branch from 124225a to 191807d May 9, 2019

@lgrahl lgrahl merged commit f6b7fef into master May 9, 2019

7 checks passed

ci/circleci: docker-build Your tests passed on CircleCI!
Details
ci/circleci: lint Your tests passed on CircleCI!
Details
ci/circleci: uitest-chrome Your tests passed on CircleCI!
Details
ci/circleci: uitest-firefox Your tests passed on CircleCI!
Details
ci/circleci: unittest-node10 Your tests passed on CircleCI!
Details
ci/circleci: unittest-node8 Your tests passed on CircleCI!
Details
license/cla Contributor License Agreement is signed.
Details

@lgrahl lgrahl deleted the push-overhaul branch May 9, 2019

@ovalseven8

This comment has been minimized.

Copy link
Contributor

commented May 9, 2019

Does this tackle #106?

@lgrahl

This comment has been minimized.

Copy link
Contributor Author

commented May 9, 2019

Dozens of things have been discussed in #106. Please elaborate. 🙂

@ovalseven8

This comment has been minimized.

Copy link
Contributor

commented May 10, 2019

@lgrahl: Today I could again reproduce #106 (12%) with https://web-beta.threema.ch. However, in this case the session could not even reconnect when I touched the smartphone and opened Threema. The session I cannot reconnect to is displayed as follows:
Screenshot_20190510-183038


Here's the log (while it's stil at 12 %):

Relevant message_log.txt
Fri May 10 18:25:10 GMT+02:00 2019	*** App launched. Version: 3.7 Build: 482 ***
Fri May 10 18:25:10 GMT+02:00 2019	Nonce count: 818
Fri May 10 18:25:10 GMT+02:00 2019	acquireConnection: source = reset, refCount = 1
Fri May 10 18:25:10 GMT+02:00 2019	startConnection
Fri May 10 18:25:10 GMT+02:00 2019	MessageServiceImpl: Queue restored. Size = 0
Fri May 10 18:25:10 GMT+02:00 2019	Starting connection
Fri May 10 18:25:10 GMT+02:00 2019	releaseConnectionLinger: source = reset, timeout = 60000
Fri May 10 18:25:10 GMT+02:00 2019	Alarm type 1 cancel
Fri May 10 18:25:10 GMT+02:00 2019	Alarm type 1 schedule in 59986ms
Fri May 10 18:25:10 GMT+02:00 2019	Scheduling Threema Safe upload. Interval = 86400000
Fri May 10 18:25:10 GMT+02:00 2019	Handling incoming GCM intent.
Fri May 10 18:25:10 GMT+02:00 2019	Received GCM message: Bundle[{google.delivered_priority=high, google.sent_time=1557505509531, google.original_priority=high, wca=R1D9eZ, wcs=56a299e0b5dc5d7a095de65a1cf3b6fc5ea0cd8351d84b538ba4360b17a6f60a, wct=1557505509, wcv=2, google.message_id=0:1557505509534232%f5f551dcf9fd7ecd}]
Fri May 10 18:25:10 GMT+02:00 2019	*** Message sent     : Fri May 10 18:25:09 GMT+02:00 2019
Fri May 10 18:25:10 GMT+02:00 2019	*** Message received : Fri May 10 18:25:10 GMT+02:00 2019
Fri May 10 18:25:10 GMT+02:00 2019	GcmMessageListenerService: Received GCM webclient wakeup for session 56a299e0b5dc5d7a095de65a1cf3b6fc5ea0cd8351d84b538ba4360b17a6f60a
Fri May 10 18:25:10 GMT+02:00 2019	[type: WIFI[], state: CONNECTED/CONNECTED, reason: (unspecified), extra: "FRITZ!Box 7430 BT", roaming: false, failover: false, isAvailable: true]
Fri May 10 18:25:10 GMT+02:00 2019	GcmMessageListenerService: Trying to wake up webclient session 56a299e0b5dc5d7a095de65a1cf3b6fc5ea0cd8351d84b538ba4360b17a6f60a
Fri May 10 18:25:10 GMT+02:00 2019	Webclient Session Wakeup: startWakeUp
Fri May 10 18:25:10 GMT+02:00 2019	Webclient Session Wakeup: start
Fri May 10 18:25:10 GMT+02:00 2019	Webclient Session Wakeup: Getting SessionInstanceService
Fri May 10 18:25:10 GMT+02:00 2019	SessionInstanceService [0]: Initialize SessionInstanceServiceImpl
Fri May 10 18:25:10 GMT+02:00 2019	Webclient Session Wakeup: Resuming SessionInstanceService
Fri May 10 18:25:10 GMT+02:00 2019	SessionInstanceService [0]: Resuming Threema Web session
Fri May 10 18:25:10 GMT+02:00 2019	ThreemaConnection state changed: CONNECTING Port: 5222 IPv6: false
Fri May 10 18:25:11 GMT+02:00 2019	ThreemaConnection state changed: CONNECTED Port: 5222 IPv6: false
Fri May 10 18:25:11 GMT+02:00 2019	SessionStateManager[0]: Session state changed from NEW to CONNECTING
Fri May 10 18:25:11 GMT+02:00 2019	Webclient Session Wakeup: Webclient session started
Fri May 10 18:25:11 GMT+02:00 2019	ch.threema.app.ThreemaApplication: WebClientListenerManager: onStateChanged
Fri May 10 18:25:11 GMT+02:00 2019	ThreemaConnection state changed: LOGGEDIN Port: 5222 IPv6: false
Fri May 10 18:25:11 GMT+02:00 2019	Run feature mask update
Fri May 10 18:25:12 GMT+02:00 2019	Handling incoming GCM intent.
Fri May 10 18:25:12 GMT+02:00 2019	Received GCM message: Bundle[{google.delivered_priority=high, google.sent_time=1557505511693, google.ttl=15, google.original_priority=high, wca=R1D9eZ, wcs=56a299e0b5dc5d7a095de65a1cf3b6fc5ea0cd8351d84b538ba4360b17a6f60a, wct=1557505511, wcv=2, google.message_id=0:1557505511695493%f5f551dc60a376ef, collapse_key=relay.56a299}]
Fri May 10 18:25:12 GMT+02:00 2019	*** Message sent     : Fri May 10 18:25:11 GMT+02:00 2019
Fri May 10 18:25:12 GMT+02:00 2019	*** Message received : Fri May 10 18:25:12 GMT+02:00 2019
Fri May 10 18:25:12 GMT+02:00 2019	GcmMessageListenerService: Received GCM webclient wakeup for session 56a299e0b5dc5d7a095de65a1cf3b6fc5ea0cd8351d84b538ba4360b17a6f60a
Fri May 10 18:25:12 GMT+02:00 2019	GcmMessageListenerService: Trying to wake up webclient session 56a299e0b5dc5d7a095de65a1cf3b6fc5ea0cd8351d84b538ba4360b17a6f60a
Fri May 10 18:25:12 GMT+02:00 2019	Webclient Session Wakeup: startWakeUp
Fri May 10 18:25:12 GMT+02:00 2019	Webclient Session Wakeup: start
Fri May 10 18:25:12 GMT+02:00 2019	Webclient Session Wakeup: Getting SessionInstanceService
Fri May 10 18:25:12 GMT+02:00 2019	Webclient Session Wakeup: Already started, store pending wakeup
Fri May 10 18:25:16 GMT+02:00 2019	Handling incoming GCM intent.
Fri May 10 18:25:16 GMT+02:00 2019	Received GCM message: Bundle[{google.delivered_priority=high, google.sent_time=1557505515890, google.ttl=90, google.original_priority=high, wca=R1D9eZ, wcs=56a299e0b5dc5d7a095de65a1cf3b6fc5ea0cd8351d84b538ba4360b17a6f60a, wct=1557505515, wcv=2, google.message_id=0:1557505515892335%f5f551dc60a376ef, collapse_key=relay.56a299}]
Fri May 10 18:25:16 GMT+02:00 2019	*** Message sent     : Fri May 10 18:25:15 GMT+02:00 2019
Fri May 10 18:25:16 GMT+02:00 2019	*** Message received : Fri May 10 18:25:16 GMT+02:00 2019
Fri May 10 18:25:16 GMT+02:00 2019	GcmMessageListenerService: Received GCM webclient wakeup for session 56a299e0b5dc5d7a095de65a1cf3b6fc5ea0cd8351d84b538ba4360b17a6f60a
Fri May 10 18:25:16 GMT+02:00 2019	GcmMessageListenerService: Trying to wake up webclient session 56a299e0b5dc5d7a095de65a1cf3b6fc5ea0cd8351d84b538ba4360b17a6f60a
Fri May 10 18:25:16 GMT+02:00 2019	Webclient Session Wakeup: startWakeUp
Fri May 10 18:25:16 GMT+02:00 2019	Webclient Session Wakeup: start
Fri May 10 18:25:16 GMT+02:00 2019	Webclient Session Wakeup: Getting SessionInstanceService
Fri May 10 18:25:16 GMT+02:00 2019	Webclient Session Wakeup: Already started, store pending wakeup
Fri May 10 18:25:16 GMT+02:00 2019	Webclient Session Wakeup: wakeup already pending, refreshing timeOfDeath
Fri May 10 18:25:53 GMT+02:00 2019	SessionState[0,CONNECTING]: Error: Timeout while connecting to remote client
Fri May 10 18:25:53 GMT+02:00 2019	SessionStateManager[0]: Session state changed from CONNECTING to ERROR
Fri May 10 18:25:53 GMT+02:00 2019	ch.threema.app.ThreemaApplication: WebClientListenerManager: onStateChanged
Fri May 10 18:26:11 GMT+02:00 2019	Alarm type 1 received
Fri May 10 18:26:11 GMT+02:00 2019	Alarm type 1 dispatch to LifetimeService START
Fri May 10 18:26:11 GMT+02:00 2019	Alarm type 1 (handling) START
Fri May 10 18:26:11 GMT+02:00 2019	stopConnection
Fri May 10 18:26:11 GMT+02:00 2019	ThreemaConnection state changed: DISCONNECTED Port: 5222 IPv6: false
Fri May 10 18:26:11 GMT+02:00 2019	MessageServiceImpl: Queue saved. Size = 0
Fri May 10 18:26:11 GMT+02:00 2019	cleanupConnection: connection closed
Fri May 10 18:26:11 GMT+02:00 2019	Alarm type 1 (handling) DONE. Duration = 13ms
Fri May 10 18:26:11 GMT+02:00 2019	Alarm type 1 dispatch to LifetimeService STOP. Duration = 14ms
Fri May 10 18:28:41 GMT+02:00 2019	Handling incoming GCM intent.
Fri May 10 18:28:41 GMT+02:00 2019	Received GCM message: Bundle[{google.delivered_priority=high, google.sent_time=1557505721364, google.original_priority=high, wca=4jlSQj, wcs=56a299e0b5dc5d7a095de65a1cf3b6fc5ea0cd8351d84b538ba4360b17a6f60a, wct=1557505721, wcv=2, google.message_id=0:1557505721367282%f5f551dcf9fd7ecd}]
Fri May 10 18:28:41 GMT+02:00 2019	*** Message sent     : Fri May 10 18:28:41 GMT+02:00 2019
Fri May 10 18:28:41 GMT+02:00 2019	*** Message received : Fri May 10 18:28:41 GMT+02:00 2019
Fri May 10 18:28:41 GMT+02:00 2019	GcmMessageListenerService: Received GCM webclient wakeup for session 56a299e0b5dc5d7a095de65a1cf3b6fc5ea0cd8351d84b538ba4360b17a6f60a
Fri May 10 18:28:41 GMT+02:00 2019	GcmMessageListenerService: Trying to wake up webclient session 56a299e0b5dc5d7a095de65a1cf3b6fc5ea0cd8351d84b538ba4360b17a6f60a
Fri May 10 18:28:41 GMT+02:00 2019	Webclient Session Wakeup: startWakeUp
Fri May 10 18:28:41 GMT+02:00 2019	Webclient Session Wakeup: start
Fri May 10 18:28:41 GMT+02:00 2019	Webclient Session Wakeup: Getting SessionInstanceService
Fri May 10 18:28:41 GMT+02:00 2019	Webclient Session Wakeup: Resuming SessionInstanceService
Fri May 10 18:28:41 GMT+02:00 2019	SessionInstanceService [0]: Resuming Threema Web session
Fri May 10 18:28:44 GMT+02:00 2019	SessionStateManager[0]: Session state changed from ERROR to CONNECTING
Fri May 10 18:28:44 GMT+02:00 2019	Webclient Session Wakeup: Webclient session started
Fri May 10 18:28:44 GMT+02:00 2019	ch.threema.app.ThreemaApplication: WebClientListenerManager: onStateChanged
Fri May 10 18:28:44 GMT+02:00 2019	Handling incoming GCM intent.
Fri May 10 18:28:44 GMT+02:00 2019	Received GCM message: Bundle[{google.delivered_priority=high, google.sent_time=1557505723578, google.ttl=15, google.original_priority=high, wca=4jlSQj, wcs=56a299e0b5dc5d7a095de65a1cf3b6fc5ea0cd8351d84b538ba4360b17a6f60a, wct=1557505723, wcv=2, google.message_id=0:1557505723580671%f5f551dc60a376ef, collapse_key=relay.56a299}]
Fri May 10 18:28:44 GMT+02:00 2019	*** Message sent     : Fri May 10 18:28:43 GMT+02:00 2019
Fri May 10 18:28:44 GMT+02:00 2019	*** Message received : Fri May 10 18:28:44 GMT+02:00 2019
Fri May 10 18:28:44 GMT+02:00 2019	GcmMessageListenerService: Received GCM webclient wakeup for session 56a299e0b5dc5d7a095de65a1cf3b6fc5ea0cd8351d84b538ba4360b17a6f60a
Fri May 10 18:28:44 GMT+02:00 2019	GcmMessageListenerService: Trying to wake up webclient session 56a299e0b5dc5d7a095de65a1cf3b6fc5ea0cd8351d84b538ba4360b17a6f60a
Fri May 10 18:28:44 GMT+02:00 2019	Webclient Session Wakeup: startWakeUp
Fri May 10 18:28:44 GMT+02:00 2019	Webclient Session Wakeup: start
Fri May 10 18:28:44 GMT+02:00 2019	Webclient Session Wakeup: Getting SessionInstanceService
Fri May 10 18:28:44 GMT+02:00 2019	Webclient Session Wakeup: Already started, store pending wakeup
Fri May 10 18:28:44 GMT+02:00 2019	Webclient Session Wakeup: wakeup already pending, refreshing timeOfDeath
Fri May 10 18:28:48 GMT+02:00 2019	Handling incoming GCM intent.
Fri May 10 18:28:48 GMT+02:00 2019	Received GCM message: Bundle[{google.delivered_priority=high, google.sent_time=1557505727769, google.ttl=90, google.original_priority=high, wca=4jlSQj, wcs=56a299e0b5dc5d7a095de65a1cf3b6fc5ea0cd8351d84b538ba4360b17a6f60a, wct=1557505727, wcv=2, google.message_id=0:1557505727771149%f5f551dc60a376ef, collapse_key=relay.56a299}]
Fri May 10 18:28:48 GMT+02:00 2019	*** Message sent     : Fri May 10 18:28:47 GMT+02:00 2019
Fri May 10 18:28:48 GMT+02:00 2019	*** Message received : Fri May 10 18:28:48 GMT+02:00 2019
Fri May 10 18:28:48 GMT+02:00 2019	GcmMessageListenerService: Received GCM webclient wakeup for session 56a299e0b5dc5d7a095de65a1cf3b6fc5ea0cd8351d84b538ba4360b17a6f60a
Fri May 10 18:28:48 GMT+02:00 2019	GcmMessageListenerService: Trying to wake up webclient session 56a299e0b5dc5d7a095de65a1cf3b6fc5ea0cd8351d84b538ba4360b17a6f60a
Fri May 10 18:28:48 GMT+02:00 2019	Webclient Session Wakeup: startWakeUp
Fri May 10 18:28:48 GMT+02:00 2019	Webclient Session Wakeup: start
Fri May 10 18:28:48 GMT+02:00 2019	Webclient Session Wakeup: Getting SessionInstanceService
Fri May 10 18:28:48 GMT+02:00 2019	Webclient Session Wakeup: Already started, store pending wakeup
Fri May 10 18:28:48 GMT+02:00 2019	Webclient Session Wakeup: wakeup already pending, refreshing timeOfDeath
Fri May 10 18:29:26 GMT+02:00 2019	SessionState[0,CONNECTING]: Error: Timeout while connecting to remote client
Fri May 10 18:29:26 GMT+02:00 2019	SessionStateManager[0]: Session state changed from CONNECTING to ERROR
Fri May 10 18:29:26 GMT+02:00 2019	ch.threema.app.ThreemaApplication: WebClientListenerManager: onStateChanged
Fri May 10 18:29:56 GMT+02:00 2019	acquireConnection: source = activityResumed, refCount = 1
Fri May 10 18:29:56 GMT+02:00 2019	startConnection
Fri May 10 18:29:56 GMT+02:00 2019	Starting connection
Fri May 10 18:29:56 GMT+02:00 2019	ThreemaConnection state changed: CONNECTING Port: 5222 IPv6: false
Fri May 10 18:29:56 GMT+02:00 2019	ThreemaConnection state changed: CONNECTED Port: 5222 IPv6: false
Fri May 10 18:29:57 GMT+02:00 2019	ThreemaConnection state changed: LOGGEDIN Port: 5222 IPv6: false
Fri May 10 18:30:00 GMT+02:00 2019	releaseConnectionLinger: source = activityPaused, timeout = 60000
Fri May 10 18:30:00 GMT+02:00 2019	Alarm type 1 cancel
Fri May 10 18:30:00 GMT+02:00 2019	Alarm type 1 schedule in 59998ms
Fri May 10 18:30:00 GMT+02:00 2019	acquireConnection: source = activityResumed, refCount = 1
Fri May 10 18:30:00 GMT+02:00 2019	another connection is already active
Fri May 10 18:30:00 GMT+02:00 2019	releaseConnectionLinger: source = activityPaused, timeout = 60000
Relevant logs from web application
[StateService] Reset states angular.js:15536:16
[WebClientService] Reset initialization steps angular.js:15536:16
Detected browser: Firefox 66 angular.js:15536:16
[SettingsService] Removing settings key: v2infoShown angular.js:15536:16
[WebClientService] Reset initialization steps angular.js:15536:16
[StateService] Reset states angular.js:15536:16
[WelcomeController] Initialize session by unlocking trusted key... angular.js:15536:16
ARIA: Attribute " aria-label ", required for accessibility, is missing on node: 
<input id="input_0" class="ng-untouched ng-valid md…ng-dirty ng-valid-parse" type="password" ng-model="ctrl.password" ng-disabled="ctrl.formLocked" autofocus="" aria-labelledby="aria-label-password-reconnect" translate-attr="{'placeholder': 'welcome.PASSWORD'}" autocomplete="current-password" aria-invalid="false" placeholder="Passwort" style="">
angular.js:15536:16
ARIA: Attribute " aria-label ", required for accessibility, is missing on node: 
<button class="md-raised md-primary md-… ng-scope md-ink-ripple" type="submit" ng-transclude="" translate="" translate-attr-aria-label="welcome.BTN_RECONNECT" aria-label="Verbindung aufbauen">
angular.js:15536:16
[VersionService] Using Threema Web version 2.1.7-reconnect-overhaul-beta6 angular.js:15536:16
[WelcomeController] Checking if the session is already open in another tab or window angular.js:15536:16
[WebClientService] Stopping (reason=stop, send=false, close=welcome, connectionBuildupState=new) angular.js:15536:16
[WebClientService] Timer stopped angular.js:15536:16
[StateService] Reset states angular.js:15536:16
[WebClientService] Reset initialization steps angular.js:15536:16
[TimeoutService] Cancelling 0 timeouts angular.js:15536:16
[WebClientService] Session closed (cannot be resumed) angular.js:15536:16
[WebClientService] Peer connection was null angular.js:15536:16
[PushService] Initialized with gcm token angular.js:15536:16
Initializing (keyStore=yes, peerTrustedKey=yes, resume=false) angular.js:15536:16
[WebClientService] Reset initialization steps angular.js:15536:16
[TimeoutService] Cancelling 0 timeouts angular.js:15536:16
Discarded previous session angular.js:15536:16
[WebClientService] Starting WebClientService... angular.js:15536:16
[WebClientService] Creating new startup promise angular.js:15536:16
[StateService] Connection buildup state: new => push angular.js:15536:16
[StateService] Signaling connection state: new => new angular.js:15536:16
[StateService] Signaling connection state: new => ws-connecting angular.js:15536:16
[Push.56a299e0b5dc5d7a095de65a1cf3b6fc5ea0cd8351d84b538ba4360b17a6f60a] Sending push 1/3 (ttl=0) angular.js:15536:16
[StatusController] State change: error -> warning angular.js:15536:16
[Push.56a299e0b5dc5d7a095de65a1cf3b6fc5ea0cd8351d84b538ba4360b17a6f60a] Push sent successfully angular.js:15536:16
[StateService] Signaling connection state: ws-connecting => server-handshake angular.js:15536:16
[StateService] Signaling connection state: server-handshake => peer-handshake angular.js:15536:16
[Push.56a299e0b5dc5d7a095de65a1cf3b6fc5ea0cd8351d84b538ba4360b17a6f60a] Sending push 2/3 (ttl=15) angular.js:15536:16
[Push.56a299e0b5dc5d7a095de65a1cf3b6fc5ea0cd8351d84b538ba4360b17a6f60a] Push sent successfully angular.js:15536:16
[Push.56a299e0b5dc5d7a095de65a1cf3b6fc5ea0cd8351d84b538ba4360b17a6f60a] Sending push 3/3 (ttl=90) angular.js:15536:16
[Push.56a299e0b5dc5d7a095de65a1cf3b6fc5ea0cd8351d84b538ba4360b17a6f60a] Push sent successfully angular.js:15536:16
[Push.56a299e0b5dc5d7a095de65a1cf3b6fc5ea0cd8351d84b538ba4360b17a6f60a] Push session timeout after 3 tries angular.js:15536:16
[Push.56a299e0b5dc5d7a095de65a1cf3b6fc5ea0cd8351d84b538ba4360b17a6f60a] Push done angular.js:15536:16
@dbrgn

This comment has been minimized.

Copy link
Contributor

commented May 13, 2019

@ovalseven8 this is out of scope regarding the client-side implementation, but a quick summary:

It seems that the app still thought it was connected when it received the pushes, and therefore ignored them. We have a system of storing "pending wakeups" in the app though, that should be processed once the connection is actually lost. However, in this case the state machine goes directly from CONNECTING to ERROR. Unfortunately, the pending wakeups are processed in the DISCONNECTED state, which is skipped (since there was never a connection).

Furthermore, the connect timeout in the app is quite long (42s). Maybe that could be reduced by a pending wakeup.

@lgrahl maybe you want to take a closer look. I've filed an internal issue for this.

@lgrahl lgrahl referenced this pull request May 13, 2019

Open

Reliable Reconnection #802

4 of 17 tasks complete
@lgrahl

This comment has been minimized.

Copy link
Contributor Author

commented May 13, 2019

Umbrella issue: #802

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.