Other error can be indications of the BE being blocked, not just
the ConnectException. We might end up in a state when the event
loop always fails in the background without trying to unblock the
network communication.
MAILAND-2980
The canceled exception happens when a flow is cancelled while the
network call is being made. As such, it should not be an indication
of the server not being reachable, nor should we retry the call
when it happens.
MAILAND-2980
This way the jobs that require network will run as soon as we determine
that the server is indeed reachable.
Additionally, changes a name of a flow to a more meaningful one.
Finally, fixes synchronisation of the hasConn function- before it was
synchronised on a boolean, which is a mistake. On top of that, the read
and the write functions were being synchronised in different ways,
using different objects as locks.
MAILAND-2980
Previously, we would restart observing the counters every time
user id, location, label or refresh flow emitted. This would result
in the counters network call being started multiple times in a sequence,
the old calls being immediately cancelled. This would throw an
IOException, which in turn was interpreted as server not reachable.
Now we only start observing the counters once, which eliminates the
behaviour described above.
MAILAND-2980
Additionally, introduces a result class to be more explicit about the
possible outcomes.
The ping worker also updates the connectivity status in the app
accordingly when the switch succeeded.
MAILAND-2981
This class is used by the ping worker- this way, when switched to
a proxy, we will try to ping the main BE with each ping worker
execution, and switch to the main BE as soon as it's available.
MAILAND-2981
This is used now at the start of the process of finding an alternative
routing. Before, the ping was executed against the current endpoint,
which would be a proxy when we were on a proxy, and thus not doing
what we wanted it to do.
MAILAND-2981
In order to check if the main backend is available even when we are
switch to a proxy, we need to always have access to the main backend.
This is achieved by injecting two instances of api to the api manager
class: one that can be reset when we switch to a proxy, and the other
one always pointing to the main BE. The main BE one is only used to
execute the ping call.
MAILAND-2981
This call is triggered from the okhttp interceptors, which are executed
on background threads, potentially concurrently. This might result
in the cache being inconsistent and holding wrong api instance for
a given URL.
MAILAND-2981
This interceptor is last in the chain. This mean it will be the last one
to process a request (without modifying it any further) and the first
one to process a response (retry the request if needed).
MAILAND-2980
This interceptor uses the TryWithExponentialBackoff class to
retry the network calls, if the call result (error or a response)
is retryable. If all the retries have failed, the result is propagated
to the next interceptor in the chain.
This commit also includes definitions of which errors and responses
are considered retryabale.
MAILAND-2980
The class now takes three blocks:
- to determine if the error is retryable,
- to determine if the result is retryable,
- to execute before each retry.
MAILAND-2980
If an error happened while trying to fetch the counters from the BE,
the flow would stop emitting. This means the counter in the mailbox
would stop updating automatically at this point.
Fixed by catching the exception on the inner flow, otherwise, if the
exception was caught on the outer flow, the inner flow would get
cancelled and stop emitting.
This is mostly a fix for excessive counter calls we make, even when
the app is in bg. Currently two calls to fetch counters are made
every 30s, even if the app is in the bg. This is quite wasteful and
puts strain on the BE (we were already made aware of the excessive
calls we make to those endpoints).
Maciej Surmacz
Zorica Stojchevska
proton-ci
Zorica Stojchevska
Denys Zelenchuk