memelabs / dggchat Goto Github PK

destinygg/chat#36

Errors are going to change to a slightly different format, so ideally for now both formats should be handled gracefully until the switch is fully made.

Also new mute parameters.

[![GoDoc](https://godoc.org/github.com/MemeLabs/dggchat?status.svg)](https://godoc.org/github.com/MemeLabs/dggchat)

[![Go Report Card](https://goreportcard.com/badge/github.com/memelabs/dggchat)](https://goreportcard.com/report/github.com/memelabs/dggchat)

I sometimes get this when trying to connect.
seems to happen randomly, I don't change anything.

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x70 pc=0x228b60]

goroutine 28 [running]:
github.com/gorilla/websocket.(*Conn).NextReader(0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/pi/go/pkg/mod/github.com/gorilla/[email protected]/conn.go:938 +0x14
github.com/gorilla/websocket.(*Conn).ReadMessage(0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /home/pi/go/pkg/mod/github.com/gorilla/[email protected]/conn.go:1028 +0x1c
github.com/Memelabs/dggchat.(*Session).listen(0x20824d0)
        /home/pi/go/pkg/mod/github.com/!memelabs/[email protected]/session.go:164 +0x24
created by github.com/Memelabs/dggchat.(*Session).open
        /home/pi/go/pkg/mod/github.com/!memelabs/[email protected]/session.go:115 +0xfc

Due to firefox tabs continually crashing on me, I quickly hit the 5 connection count cap (https://github.com/destinygg/chat/blob/master/connection.go#L138).

Rather than outright rejecting new connections, would it make sense to close old connections (resetting to 0) and allowing new connections?

I'd be perfectly willing to put in a patch/PR should anyone have any input on this.

ian@home ~ $ netstat | awk '/destiny/'
tcp        0      0 192.168.1.4:53654       destiny.gg:https        ESTABLISHED
tcp        0      0 192.168.1.4:54422       destiny.gg:https        ESTABLISHED
tcp        0      0 192.168.1.4:54232       destiny.gg:https        ESTABLISHED
tcp        0      0 192.168.1.4:54588       destiny.gg:https        ESTABLISHED
tcp        0      0 192.168.1.4:53466       destiny.gg:https        ESTABLISHED

I believe @SoMuchForSubtlety is having this issue

Right now errors are handled by the errorHandler, but it's not possible to determine for what message the error was and thus handling it is not really possible.

It is possible to determine if the message was sent successfully if we wait for the ws to respond with either an error or confirmation.
There would need to be a mutex for the ws that gets locked every time we send a message until confirmation is received to prevent getting errors or confirmation meant for a different message.

Transition to using github actions over travis