Notifications need page refresh

[m-dijk]

Context: Install Zou "0.12.30" / kistu "0.12.35" on Ubuntu 18.04.5 LTS I've followed installation instruction on https://zou.cg-wire.com http://srvkitsu/socket.io returns JSON {"name":"Zou Event stream"}

Problem: Assigning a task to a user is working great, but the user doesn't get notifications. He has to refresh the page (F5) to see his recently assigned tasks. We encounter the same problem while changing the task status which make me think of a global problem with notifications..

What I have tried :

• turn on debuging mode in gunicorn, trying to track down the problem but didn't find anything relevant.
• @jenius suggestion: https://github.com/cbsrobot/zou/commit/0034105dc63265227276764584fc9e1927bd31fd which solves the error code 405 when POSTing on socket.io

In the attached zip you will find :

• gunicorn files
• gunicorn error logs (zou and zou-events)
• gunicorn's zou access logs (zou-events are empty)
• nginx access logs
• result of 'pip freeze' in requirements.txt (just in case)
• both services configuration files zou_issue.zip

[frankrousseau]

Hello @m-dijk

It seems to be a problem with your event server. It looks like the application can't connect to it. Can you verify your Nginx configuration?

[2-REC]

Hello @frankrousseau

I encounter the same issue with the page not refreshing automatically the notifications. I have followed different ways of installing Zou+Kitsu, but have the same issue with all.

About the Nginx configuration, I tried both the one provided in the Zou installation doc (on CG-Wire website), as well as the configuration used in the Docker image (from the Kistu Docker Github). (with and without changing the 'server_name' value)

Is there anything else to set/install?

I tried with the latest source as well as with older versions for both Zou and Kitsu (just retried with Zou 0.12.43 and Kitsu 0.12.48).

Derek.

PS: I am using a clean installation of Ubuntu 20.04.1

[frankrousseau]

This is the configuration we use on our servers, if it can help:

    location /socket.io {
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";

        chunked_transfer_encoding off;
        proxy_buffering off;
        proxy_cache off;

        proxy_pass http://localhost:5001;
    }

[m-dijk]

Hi @frankrousseau,

Thanks for sharing your configuration file, but it didn't help.. On page load, Kitsu make several GET request to URL like http://srvkitsu/socket.io/?EIO=3&transport=polling&t=NW1fLLJ which all return 200 OK so there is no connection problem between kitsu an socket.io.. After each GET request Kitsu also make POST request with payload 1:1. Those POST request are also returning 200 OK..

Just to clarify, here is my complete nginx conf file:

server {
    listen 80;
    server_name srvkitsu.xxx.zy;

    location /api {
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_pass http://localhost:5000/;
        client_max_body_size 500M;
        proxy_connect_timeout 600s;
        proxy_send_timeout 600s;
        proxy_read_timeout 600s;
        send_timeout 600s;
    }

    location /socket.io {
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
        chunked_transfer_encoding off;
        proxy_buffering off;
        proxy_cache off;
        proxy_pass http://127.0.0.1:5001/;
    }

    location / {
        autoindex on;
        root  /opt/kitsu/dist;
        try_files $uri $uri/ /index.html;
    }
}

[frankrousseau]

If you have 200 status codes, it means that everything is working fine.

[frankrousseau]

@2-REC The problem seems to be on your side. With the latest version everything seems to work fine.

[m-dijk]

Hi ! I finally found the reason why some of us are facing this issue. It looks like zou-event is forced to use an Ident connection to Postgres, while zou is not.. For people who have been following the installation instruction the solution is to edit pg_ident.conf and add a map for the user zou (on ubuntu you find this file in /etc/postgresql/_versionnumber/main/pg_ident.conf). Like this :

# MAPNAME       SYSTEM-USERNAME         PG-USERNAME
postgres        zou                     postgres

Found the solution thanks to the following error "on_error() missing 1 required positional argument: 'data'" while setting up event listner

[frankrousseau]

Wow that's very interesting. Especially because zou-events doesn't use Postgres. Thank you for the report. The error should be more explicit too.

[m-dijk]

OK, that's weird indeed.

In the documentation it's also missing the part with the SECRET_KEY env var that has to be set in the file /etc/systemd/system/zou-events.service (which has to be the same as the one defined in the file /etc/systemd/system/zou.service).

I'm pretty sure I set this env var in my first setup, but if it can't be related to postgres then it has to be that one.. I agree, it would be helpfull to have a more explicit error in gunicorn-event error log ;)

Marc