a semi workaround is changing the buffer size manually, but it wont stop the websocketpeer from stalling when its full.

func _ready():
	socket = WebSocketPeer.new()
	socket.connect_to_url("ws://localhost:8765/")
	socket.inbound_buffer_size = NEW SIZE
	socket.outbound_buffer_size = NEW SIZE

We have some work being done to fix this, we made a PR upstream to see if Godot will take it first. godotengine/godot#98167

@SkogiB Out of curiosity, have you guys determined a criteria for how long is reasonable to wait for a PR to be merged upstream by Godot?

I think it's good that y'all are trying to get some of your fixes merged upstream. As long as it doesn't cause too long of a delay. Having an upper limit of "waiting for Godot" time would probably be a good thing to consider.

Maybe it could even be a variable limit depending on the severity of the issue. Lower severity issues can prolly afford to wait a bit longer, while higher severity issues have a shorter time limit.

IDK just spitballing ideas.

@SkogiB Out of curiosity, have you guys determined a criteria for how long is reasonable to wait for a PR to be merged upstream by Godot?

I think it's good that y'all are trying to get some of your fixes merged upstream. As long as it doesn't cause too long of a delay. Having an upper limit of "waiting for Godot" time would probably be a good thing to consider.

Maybe it could even be a variable limit depending on the severity of the issue. Lower severity issues can prolly afford to wait a bit longer, while higher severity issues have a shorter time limit.

IDK just spitballing ideas.

#709

@SkogiB Out of curiosity, have you guys determined a criteria for how long is reasonable to wait for a PR to be merged upstream by Godot?

I think it's good that y'all are trying to get some of your fixes merged upstream. As long as it doesn't cause too long of a delay. Having an upper limit of "waiting for Godot" time would probably be a good thing to consider.

Maybe it could even be a variable limit depending on the severity of the issue. Lower severity issues can prolly afford to wait a bit longer, while higher severity issues have a shorter time limit.

IDK just spitballing ideas.

We discussed it the other day after receiving some concerns from contributors and changed the practice. We may still submit upstream, but we're not going to expect it of contributors nor bog down our dev cycle waiting on Godot, as that defeats the purpose of the project.

The TCP fix for this is already in the 4.3 betas, as Norrox linked, we were just waiting to see what Godot did with our PR to merge the 4.4 dev one. They introduced their own in-house message handling instead of taking our PR so really we're not sure what to do on 4.4, but for the 4.3 betas it's already in and we got a lot of testing from Chocolate Chip and Keros showing its working well.

We discussed it the other day after receiving some concerns from contributors and changed the practice. We may still submit upstream, but we're not going to expect it of contributors nor bog down our dev cycle waiting on Godot, as that defeats the purpose of the project.

Nice I had a similar concern as well so I'm glad y'all have discussed this. Since the fix for this has already been merged into the beta I think it's prolly safe to close this issue. Unless y'all want to keep it open until it gets into a stable release. I guess I'll let y'all decide whether to close or not.

Yeah we'll probably close it before long, especially once we decide what do with 4.4dev given that they have their own weird fix that's separate from ours.