Sudden disconnects/logouts

madtheos

Hi, I'm experiencing an issue where the browser logs out if I refresh the page or if there is the slightest network interruption. If I have the "keep me logged in" ticked, then after a sudden flash of the login screen, I'm logged right back in. But this leads to loss of unsaved work and is clearly abnormal. I'm also seeing the same thing while using the progressive web app.

I don't see any corresponding errors in the logs.

I have a docker set up (over intel-proxmox-debian):

    r3:
        build:
            context: https://github.com/r3-team/r3_docker.git#main
            args:
                r3_db_host: r3_db
                r3_os_arch: x64
                r3_version: ${R3_VERSION:-3.7}
                im_policy: /etc/ImageMagick-6/policy.xml
        container_name: r${R3_VERSION:-3.7}_app
        image: "r3/${R3_VERSION:-3.7}"
        depends_on:
            - r3_db
        ports:
            - "14000:80"
        restart: unless-stopped
        volumes:
            - data_app:/opt/r3/data

lsw-fabian

Hello madtheos and welcome to the forum,

did you use a proxy in between? Because REI3 rely on websockets you have to increase the re-connect time, or complety disable this feature on your proxy if possible.

madtheos

lsw-fabian Hello Fabian, and thanks for the reply.

I'm using Cloudflare Tunnels to expose the service. They have a re-connect timeout of 100 seconds I believe, while for me the disconnect is happening within milliseconds (of any network glitch).

p. s. I'm also getting logged out if I refresh the browser page (in the local network when not using any proxy). Is this an inherent problem with this websockets approach?

regards,
Matt

gabriel

madtheos

Hello Matt,

I worked on the Websocket implementation in REI3 so I think I can give a good answer. Because websocket is a persistent data-exchange connection between server & client, proxies can cause issues as they (often by default) disconnect clients after certain time limits.

But using Websocket as a prototocol does not necessitate by itself that the client needs to reload completely, when the connection breaks (as it does now). It was implemented like that, because our main focus is on onprem deployments and it was easier to reload the client after the connection was lost (which would almost never happen in local environments). When running REI3 publicly and with bad connections, this can become an issue - and because more organizations are using REI3 this way, we need to improve our code so that it can more gracefully handle these disconnects. Websocket connections will still die on disconnect and will require some time to re-establish themselves, but the client could handle this much better.

I do not have an ETA, when we will work on it - but it´s bugging me as well and I would love to be able to address it with our next feature release.

madtheos

gabriel Thanks, that was informative. Just one more question. AFAIK, Cloudflare has a timeout of 100 seconds on websockets. Shouldn't that keep me logged in in case of a brief interruption? Is it normal that I am logged out instantly?

regards,
Matt

gabriel

madtheos Yes that is normal. Because we are currently reloading the client after re-connect, you are logged out (and then re-logged in if you chose that option).

Websocket connections are meant to be persistent. And while we can improve our code to handle it better, it will always be a bad experience if you get regular disconnects.

madtheos

gabriel By disconnect, I don't mean a network interruption that lasts a minute or 30 seconds, I mean an interruption that lasts milliseconds. One dropped packet and I'm logged out. If that is by design, it seems a tad too sensitive. Can you confirm this?

Can you also explain why the normal websocket timeouts measured in tens of seconds are not applicable?

regards,
Matt

gabriel

madtheos I am regularly traveling and even with regular, short mobile service interruptions, it rarely happens that my websocket connection dies. I cannot comment on what the cutoff points are or how many packets can be lost, because I never ran these tests. I also never ran REI3 through Cloudfare.

As I said before, we´ve not yet optimized the REI3 client for difficult network connections, because its primary mode of operation is local and on-premise. When we are going to tackle this issue, we will put in time and effort to run benchmarks and find ways to handle disconnects better, and if possible, try to avoid premature disconnects. There is little else I can say, before we work on the issue.