ValueError('Unexpected binary attachment') on Client
See original GitHub issueHello,
I am using socketio sync client with Flask-socketio server. I am hitting this exception “Unexpected binary attachment” every once in a few hours of operation. The client(s) and server are constantly communicating during this time. The rate of messages is < 50 messages per second from servers standpoint.
I use Flask-socketio as a hub. Clients connect to the server, and the server (hub) allows clients to talk to each other (via message header that has src/dst for routing). In this case the client is in the process of communicating with multiple other client(s), with server being the relay. The client communicates with other client(s) in a serial fashion (there are no parallel requests made at the same time.
Versions
client:
(venv) ~/dev/at$ pip freeze | grep -i socket
python-socketio==4.2.0
websocket-client==0.57.0
(venv) ~/dev/at$ pip freeze | grep -i engine
python-engineio==3.8.2.post1
server
(venv) bhakta@server:~/dev/controller$ pip freeze | grep -i engine
python-engineio==3.10.0
(venv) bhakta@server:~/dev/controller$ pip freeze | grep -i socket
Flask-SocketIO==4.2.1
python-socketio==4.3.1
socketIO-client==0.7.2
websocket-client==0.56.0
The client hangs up on this exception.
Exception in thread Thread-250165:
Traceback (most recent call last):
File "/usr/lib64/python3.6/threading.py", line 916, in _bootstrap_inner
self.run()
File "/usr/lib64/python3.6/threading.py", line 864, in run
self._target(*self._args, **self._kwargs)
File "/home/bhakta/dev/at/venv/lib/python3.6/site-packages/socketio/client.py", line 552, in _handle_eio_message
if pkt.add_attachment(data):
File "/home/bhakta/dev/at/venv/lib/python3.6/site-packages/socketio/packet.py", line 118, in add_attachment
raise ValueError('Unexpected binary attachment')
ValueError: Unexpected binary attachment
I event put a pdb at the Value error place to inspect the conditions
(Pdb) self.attachment_count
1
(Pdb) self.attachments
[b'PING 192.168.90.2 (192.168.90.2) 56(84) bytes of data.\n64 bytes from 192.168.90.2: icmp_seq=1 ttl=64 time=30.0 ms\n64 bytes from 192.168.90.2: icmp_seq=2 ttl=64 time=30.1 ms\n64 bytes from 192.168.90.2: icmp_seq=3 ttl=64 time=30.1 ms\n64 bytes from 192.168.90.2: icmp_seq=4 ttl=64 time=30.0 ms\n64 bytes from 192.168.90.2: icmp_seq=5 ttl=64 time=30.0 ms\n64 bytes from 192.168.90.2: icmp_seq=6 ttl=64 time=30.0 ms\n64 bytes from 192.168.90.2: icmp_seq=7 ttl=64 time=30.0 ms\n64 bytes from 192.168.90.2: icmp_seq=8 ttl=64 time=30.1 ms\n64 bytes from 192.168.90.2: icmp_seq=9 ttl=64 time=30.0 ms\n64 bytes from 192.168.90.2: icmp_seq=10 ttl=64 time=30.0 ms\n\n--- 192.168.90.2 ping statistics ---\n10 packets transmitted, 10 received, 0% packet loss, time 45033ms\nrtt min/avg/max/mdev = 30.050/30.079/30.148/0.113 ms\n']
(Pdb)
I have searched for this error without any luck for previous instances . I need some help to figure what is happening.
More importantly, I am concerned that this exception hangs the client and there is no way to recover than press Ctrl-C and restart the client. I would have liked it if the message was discarded (so application can re-try).
- Any clues on what might be happening? I am willing to provide any additional information you might need. I am able to consistently reproduce the problem every few hours
- Am I using the right set of package versions?
- Is there a way to avoid the exception so application can proceed? The current behavior of the thread exception hangs the app.
Issue Analytics
- State:
- Created 4 years ago
- Comments:11 (4 by maintainers)
Thanks Miguel, for checking the code.
I have tried to extract the code to create a minimal example but that has’t helped reproduce the issue.
I am currently working on trying to create an example where the problem can be reproduced. I will post back to this thread once I have a failing-example.
I reviewed the code and I don’t really see how the packets can get mixed up if the emits are never running at the same time. Any chance you can create a small example application that I can use to test and reproduce this behavior?