ValueError: invalid literal for int() with base 10: b'%'

[Schnodderbalken]

I'm sorry but it seems that your measure discussed in here #37 did not entirely fix the problem.
I continued implementing my frontend part and now problems occurred again.

Exception in thread Thread-27:
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/threading.py", line 914, in _bootstrap_inner
    self.run()
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/threading.py", line 862, in run
    self._target(*self._args, **self._kwargs)
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/socketio/server.py", line 444, in _handle_eio_message
    pkt = packet.Packet(encoded_packet=data)
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/socketio/packet.py", line 33, in __init__
    self.attachment_count = self.decode(encoded_packet)
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/socketio/packet.py", line 74, in decode
    self.packet_type = int(ep[0:1])
ValueError: invalid literal for int() with base 10: b'%'

Strange: if I print the payload the library tries to decode it's not even a binary string. It's some other request. So if there are many requests - some having binary content in a dictionary and some having only string content in a dictionary - there seems to be a confusion about the different requests.

[miguelgrinberg]

Okay. Looking at my fix from the other day, while it is a step in the right direction, does not do much to prevent the case of packets that are accepted into the system in the wrong order.

Strange: if I print the payload the library tries to decode it's not even a binary string. It's some other request.

This is indeed strange. The error message above suggests the payload was binary, starting with the % character, likely the first character in the PDF data.

[miguelgrinberg]

@Schnodderbalken could you try downgrading python-engineio to 0.9.1 and retest? If my theory is correct, you will not be able to get the error with 0.9.1.

[Schnodderbalken]

@miguelgrinberg I did some changes to my application which led to this problem not occurring anymore (although this might only addresses the symptoms).
Now I'm having a hard time putting the application state back to where it did not work. Frontend and backend are separated git repos and I thought I'd only have to git checkout thehashwhereithinktheproblemhappened but that does not put it in the original state.

The assumption that it could be connected to the version of python-engineio looks reasonable to me. That could explain why the problems only started since I upgraded my applciation to python 3.5 (including the corresponding dependencies which python-engineio 0.9.2. might be one of).

I'm sorry I can not validate your assumption right now. I will report whenever this happens again.

[Schnodderbalken]

The bug happened again. Downgrading python-engineio to 0.9.1 did the trick. Do you know how to fix it then? Or can I assist any further?

[miguelgrinberg]

@Schnodderbalken I know what the problem is, but I don't have a fix ready yet. No problem with staying on 0.9.1. The 0.9.2 release has what I expected would be a performance improvement, but it affected the handling of multi-packet payloads.

[Schnodderbalken]

Alright then I will stick with the old version until it's fixed. Thank you.

[miguelgrinberg]

You can now upgrade to python-socketio 1.5.0, and this problem should be gone. Note that this upgrade should also carry an upgrade to python-engineio 1.0.0.

[Schnodderbalken]

Perfect, thanks for the effort.