polytonic / sputnik Goto Github PK

Suggested here.

When one client sends a message, other clients should see that message.

Right now:

Full Chatlog:
    Bouncer (Client 1): "hi"
    Bouncer (Client 2): "hi"
    Random person: "hi"

Client 1 Chatlog:
    Bouncer (Client 1): "hi"
    Random person: "hi"

Client 2 Chatlog:
    Bouncer (Client 2): "hi"
    Random person: "hi"

Repro steps:

1. start the bouncer (locally or on a server)
2. add a server (either through code or through the frontend)
3. connect to the bouncer through HexChat
4. join a channel (e.g. testing12345)
5. disconnect from the bouncer (close hexchat)
6. connect to the bouncer again
7. join the same channel (testing12345) - failure
8. join a different channel (e.g. testing55555) - success

1. Add a network using the web interface
2. Connect via hexchat (untested on others)
3. Join a channel, send a test message
4. Join the same channel from another connection (direct to that network, not through the bouncer)
5. Disconnect from hexchat
6. Send multiple messages using the other connection
7. Reconnect via hexchat
8. Messages are replayed, but some are duplicated (i.e. "1", "2", "3", "4", "5", "4", "5" where the last two were duplicated).

Per the Heroku Deploy Button documentation, submodules are currently not supported.

Heroku Button will not work with repos that have Git submodules. Heroku Button relies on the Build API and uses tarballs fetched from GitHub. GitHub does not include submodule contents when repo-content tarballs are generated.

I've added a workaround in c5913ac by copying the script to our repository, but this should be replaced with the submodule link once submodule support is implemented for Heroku Deploy Buttons.

Configure environment
There was an issue setting up your app environment.
That add-on plan is only available to select users.

After connecting to my bouncer instance in HexChat, I asked HexChat to display the channels list in irc.freenode.net, this error occurred partway through the output. Operation continued as normal but I did see this error message:

Exception in callback <bound method _SelectorSocketTransport._read_ready of <asyncio.selector_events._SelectorSocketTransport object at 0x7ffa6c07b828>>()
handle: Handle(<bound method _SelectorSocketTransport._read_ready of <asyncio.selector_events._SelectorSocketTransport object at 0x7ffa6c07b828>>, ())
Traceback (most recent call last):
  File "/usr/lib/python3.4/asyncio/events.py", line 39, in _run
    self._callback(*self._args)
  File "/usr/lib/python3.4/asyncio/selector_events.py", line 466, in _read_ready
    self._protocol.data_received(data)
  File "sputnik/network.py", line 128, in data_received
    data = data.decode()
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb7 in position 23575: invalid start byte

The Edit command on the front end generates a race condition for database access in the backend resulting in the edited network being completely removed from the database.

Steps to Reproduce:

1. Have bouncer running with at least 1 network connection
2. Use frontend Edit command to change something (other than network name) in a connected network
3. Save changes to edited network

Expected Result:
Database has an entry for the edited network containing the updated information.

Observed Result:
Database does not contain the edited network at all.

Notes:
I believe that this can be tracked down to a race condition. The Edit command is essentially a joined Remove and Add command, but these functions are called on asynchronous objects. It is possible for the Add sub-command to execute its database operation (from add_network() in bouncer.py) before the Remove sub-command executes its database operation (from connection_lost() in network.py). Since they are both changing the same key in the database, the end result is that the Remove sub-command "wins" and removes the updated network info from the database.

Since the database access in the Add sub-command happens immediately but the database access in the Remove sub-command requires the connection to close, this non-deterministic behavior results in the unwanted outcome in the vast majority of the time (in my experience 100% of the time).

I asked HexChat for the channel list and PingPong started throwing this error:

[C to B]        PING LAG3434827238
[N to B]        ds.casparcg.com
Exception in callback <bound method _SelectorSocketTransport._read_ready of <asyncio.selector_events._SelectorSocketTransport object at 0x7ffa6c07b828>>()
handle: Handle(<bound method _SelectorSocketTransport._read_ready of <asyncio.selector_events._SelectorSocketTransport object at 0x7ffa6c07b828>>, ())
Traceback (most recent call last):
  File "/usr/lib/python3.4/asyncio/events.py", line 39, in _run
    self._callback(*self._args)
  File "/usr/lib/python3.4/asyncio/selector_events.py", line 466, in _read_ready
    self._protocol.data_received(data)
  File "sputnik/network.py", line 139, in data_received
    elif l[1] == "PONG": self.forward("PONG", l[2])
IndexError: list index out of range

The current automatic channel reconnect for a new network object does not work on Quakenet (and possibly other networks).

Steps to Reproduce:

1. Connect the bouncer to Quakenet using front-end.
2. Connect client to Quakenet through bouncer.
3. Connect to some number of channels (I used variants of #test12345).
4. Turn off your client and bouncer.
5. Restart the bouncer.
6. Reconnect client to Quakenet through bouncer.

Expected Result:
Bouncer automatically connects to Quakenet and the given channels.

Observed Result:
Bouncer automatically connects to Quakenet, but it does not join any channels automatically.

Notes:
From looking through the bouncer output, it is correctly identifying the channels to join in the database and firing the JOIN commands. Unsure of why they are not accepted.

Also, the expected behavior is observed on other networks, including freenode.

Speculation:
Perhaps the JOIN command is being sent to Quakenet too early?