[BUG] Repeated errors from Portal after websocket disconnect

Describe the bug

I am trying to troubleshoot a websocket disconnection error; I have CloudFlare in front of nginx, which proxies to a docker instance of evennia/evennia:latest. In troubleshooting, I’m seeing odd behaviour where the Portal continues to repeatedly log an error, even after the web client and session have gone away. I understand that the websocket disconnection is kind of a complicated edge case, but the fact that it continues to log errors until restarted suggests that the session isn’t being cleaned up upon disconnection.

To Reproduce

Steps to reproduce the behavior:

1. While running evennia in Docker, have a nginx reverse proxy. Have evennia use WEBSOCKET_CLIENT_URL = "wss://mud.domain.com/ws" and
2. Configure CloudFlare origin to point to your server
3. Connect with webclient and wait for session to disconnect.
4. See error below – Even after the browser session is logged-out and closed completely, the errors will continue to be logged by the evennia Portal.

Expected behavior

It sounds like the back-end isn’t aware that the webclient has disconnected. I’d expect it to not continue to send data and throw exceptions.

Environment, Evennia version, OS etc

    Evennia 0.9.0
    OS: posix
    Python: 3.7.7
    Twisted: 19.10.0
    Django: 2.2.12

Additional context

20-04-14 17:32:07  |Portal| [::] Traceback (most recent call last):
20-04-14 17:32:07  |Portal| [::]   File "/usr/src/evennia/evennia/server/portal/portalsessionhandler.py", line 454, in data_out
20-04-14 17:32:07  |Portal| [::]     getattr(session, funcname)(*cmdargs, **cmdkwargs)
20-04-14 17:32:07  |Portal| [::]   File "/usr/src/evennia/evennia/server/portal/webclient.py", line 276, in send_text
20-04-14 17:32:07  |Portal| [::]     self.sendLine(json.dumps([cmd, args, kwargs]))
20-04-14 17:32:07  |Portal| [::]   File "/usr/src/evennia/evennia/server/portal/webclient.py", line 194, in sendLine
20-04-14 17:32:07  |Portal| [::]     return self.sendMessage(line.encode())
20-04-14 17:32:07  |Portal| [::]   File "/usr/local/lib/python3.7/site-packages/autobahn/websocket/protocol.py", line 2216, in sendMessage
20-04-14 17:32:07  |Portal| [::]     raise Disconnected("Attempt to send on a closed protocol")
20-04-14 17:32:07  |Portal| [::] autobahn.exception.Disconnected: Attempt to send on a closed protocol

Relevant sections of nginx config:

upstream mud_backend {
  server 192.0.0.x:4001;
}

upstream mud_ws_backend {
  server 192.0.0.x:4002;
  keepalive 10;
}
...
    location ~ /ws {
      include snippets/proxy_headers.conf;
       proxy_http_version 1.1;
       proxy_set_header Upgrade $http_upgrade;
       proxy_set_header Connection "upgrade";
       client_max_body_size 1024M;
       proxy_set_header X-Frame-Options SAMEORIGIN;
       proxy_read_timeout 86400;
       proxy_send_timeout 86400;
       proxy_buffering off;
       
       proxy_pass http://mud_ws_backend;

   }

[trhr]

Multiple PR candidates are being floated that should resolve this and other portal bugs.

[Griatch]

This was handled in the webclient protocol by catching the exception and direct it to close the connection.