Skip to content

Fixed an issue with WebRTC signaling example server parsing #1214

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

misaim
Copy link

@misaim misaim commented Jun 15, 2025

Went to try out the WebRTC Signaling example - hit Listen, and then connect, and got an error.
I then tried the included node server, which worked perfectly.

After adding some debugging prints, I found an issue within _parse_msg - JSON numbers are always parsed as a float, and so this code:

if not str(parsed.type).is_valid_int() or not str(parsed.id).is_valid_int():
    return false

fails, as these are both floats (and not valid ints).

Checks have been adjusted for both equality (x=int(x)) and type equality (typeof(x) = TYPE_FLOAT), for both the message ID and type.

This means the demo will run correctly, as previously the server could be started from the UI, but not joined, at least via a desktop environment with webrtc Gdextension.

…umbers are always parsed as a float, so checks have been added for both equality (x=int(x)) and type equality (typeof(x) = TYPE_FLOAT), for both the message ID and type.\n This means the demo will run correctly, as previously the server could be started from the UI, but not joined, at least via a desktop environment with webrtc Gdextension.
@Calinou Calinou added the bug label Jun 24, 2025
Comment on lines +210 to +212
if not typeof(parsed.type) == TYPE_FLOAT and int(parsed.type) == parsed.type:
return false
if not typeof(parsed.id == TYPE_FLOAT) and int(parsed.id) == parsed.id:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The parentheses for typeof() don't end at the same position in both checks, is that intended?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would check the type of bool, and then check if that is 0 or not, that doesn't seem right

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants