Closed Gobot1234 closed 4 years ago
Doing the same with the response also raises a similar error KeyError: 'int32'
which sort of makes me think that it's a proto error.
Thanks for reporting this. To investigate further it would be helpful if you could also provide a sample payload as JSON that produces the problem, and maybe also the proto definition (ideally a more minimal example) to help compose a failing test case similar to the others we've collected: https://github.com/danielgtaylor/python-betterproto/tree/master/betterproto/tests#test-case-directory-structure
In the mean time, is it possible that this is a protobuf versioning problem? Have any fields changed order or type?
I don't think I can provide a JSON as the messages are just pulled from chrome's websocket viewer. I'm rather new to this proto thing so if you have any clue how I could get a JSON payload that would be great.
The protobufs that these were compiled from can be found at https://github.com/SteamDatabase/Protobufs/blob/master/steam/steammessages_clientserver_login.proto
I will try and recompile them, and see if that changes anything though.
Thanks.
Recompiling didn't change anything.
Error seems to happen here:
⚠ KeyError: 'uint32'
The Bytes from the stacktrace should serve well enough as test-case data
b"\x8a\x15\x00\x80\t\x00\x00\x00\t\xc2L'\x11\x01\x00\x10\x01\x08\xac\x80\x048\xc4\xfa\xff\xff\x0f\xa8\x01\x02\x80\x02\x04\x88\x02\x02\x92\x03\ngobot12342\xa0\x06\x00\xba\x068gvvcXnEbE1YAAAAAAAAAAAAAAAAAAAAAAwDUJifU4Ce9czLf/NN85VZV"
At first glance, it seems a simple fix, just add the TYPE to the array with correct binary value, but who knows :-)
I'll try that and see what happens
That appeared to fix it
I had a go at debugging this and it looks like what's happening is that the parse_fields function is deducing from the input data that the field's wire type should be 64bit value (specifically it produces ParsedField(number=1, wire_type=1, value=b"\xc2L'\x11\x01\x00\x10\x01", raw=b"\t\xc2L'\x11\x01\x00\x10\x01")
) despite the fact that the field is declared as uint32.
How this discrepancy arises or what to make of it, I don't know... I guess it means there's a mismatch between the number of bytes to be unpacked and the method of unpacking to apply?
Whether it would be valid to proceed to unpack the result as an int32 anyway is also not clear to me, but the case could clearly be handled better than raising a KeyError.
As for the root cause, the google grpcio implementation also chokes on this example with:
RuntimeWarning: Unexpected end-group tag: Not all data was converted
Which makes me suspect there is actually either some kind of data corruption or more likely a breaking change in the protobuf between the proto file in the repo and that data sample.
Great work investigating!
How this discrepancy arises or what to make of it, I don't know... I guess it means there's a mismatch between the number of bytes to be unpacked and the method of unpacking to apply?
The docs also lists specifically which types are interchangeable (for example, when you upgrade a message type from int32 to int64). From this list it is shown that int32 cannot be upgraded to fixed64 or vise-versa.
Then google grpcio also doesn't handle this case correctly.
It seems rather that the sending server has updated its format, and the client needs to update as well. I've tried to look through https://github.com/SteamDatabase/Protobufs/blame/master/steam/steammessages_clientserver_login.proto for any fields that had its type changed, but couldn't find any (its a big file!).
If we can pinpoint a commit on the source proto that shows an incompatible change was made, we know for sure this is not a bug in protobuf/betterproto.
👉 Do we know which message and field is actually causing the error?
@boukeversteegh I forgot to report which field it was before I cleaned up my debug setup, but as the ParsedField object shows it's a uint32 field number 1 of its containing object, and wasn't the first or last part of the message so one of:
I think that the header on the message is messing with it. This therefore isn't an issue with the library.
Hello, I am trying to parse a protobuf that was received from a websocket.
I'm not too sure what causes this issue, not too sure if it is the dataclass that I am using or a library error so I thought I better ask.
Version Info
Python Version: 3.7.5 Betterproto: 1.2.5
Thanks 👍