Open kennethloeffler opened 11 months ago
If we're going to fix this by closing a client's open subscribe requests once the client disconnects, it will require a new "disconnect" endpoint, and the addition of some sort of session or client ID to the subscribe endpoint.
I'd rather us make a minimal repro and try to get Roblox to fix it... but it just sucks, because at the same time, I think it's fairly high priority. Users often rapidly disconnect-reconnect when first trialing the software, and this behavior makes them think Rojo is slow and bad - when really, it's just that Roblox somehow ended up in a situation where more than 3 open requests is impossible -_-
I've gone ahead and reported this issue here: https://devforum.roblox.com/t/httpservice-only-allows-3-in-flight-requests-at-a-time/2673475
I got some information from a user that suggests this may not be reproducible on Rojo 6.2. We should try the repro here on Rojo 6.2 to see if there is a change from then to now that resulted in a regression.
I got some information from a user that suggests this may not be reproducible on Rojo 6.2. We should try the repro here on Rojo 6.2 to see if there is a change from then to now that resulted in a regression.
I've just tried this, and the problem is still reproducible on Rojo 6.2.0 as I expected
Reproduction steps:
rojo serve
on it.I've attached a packet capture and the Rojo plugin's trace logs to help illustrate the problem: rojo-trace-and-pcap.zip
Inspecting them together reveals that when the problem occurs, Roblox Studio is waiting for previous subscribe requests to time out before sending the initial info request. We can fix this by adding some functionality that closes any open requests once a client disconnects, but it is a little strange that Roblox Studio is blocking like this...