Feedback Quick Join is rubbish

Hey spinaljack, Thanks for the feedback, definitely a bunch of reasonable things to think about. Since there's lots of text below, I just wanted to throw out here that you can reach out to me in the Unity Discord channel as well (Veleek#3000) if you have any other questions or follow ups based on the following.

1. Yes, the limit for this is rather low. We're looking into adjusting this and we're planning on making a change in the next few weeks. See below, for a more in-depth discussion about the what and why below.
2. This was an explicit design decision made by the team. As part of a create call, there's a whole bunch of extra metadata that you need to provide and in many cases this data isn't available if the client is quick joining and it doesn't make sense to require them to specify things like "Max Players" or "Lobby Name" if they're not going to be used if they QuickJoin. We considered adding an optional "Create if no match found" flag to the QuickJoin request and allow the caller to specify all this data as part of the QuickJoin request, but determined that it was easier for the developer to implement the flow on their side to either automatically call Create if quick join fails or redirect the user to a UI to create a match otherwise. If we continue to get feedback that this is a scenario that developers want to be handled automatically we could consider doing so (and may do so just by wrapping the API in the client SDK instead of adding something on the service side).
3. I'm not sure exactly what problem you're referring to here. Quick Join should, essentially, find a whole bunch of lobbies that match and attempt to join them one at a time until one succeeds (or it times out). You may be running into a specific edge case that we're not handling, but if you can provide more detail we're happy to dig into it. Also, the rate limit changes we're looking into should help out with this even in the cases where you're failing unexpectedly.


Okay, so now just a bunch of extra talk about the what and why for QuickJoin:

Originally we used to internally retry in the Lobby service where it would spin for 10 seconds repeatedly searching for and attempting to join rooms, so it made more sense to limit the number of calls to once per 10 seconds to avoid concurrent requests. This has since been change to only 1 second mostly because we think that if we don't succeed within 1 second, we're probably not going to succeed later and we don't want to make the client wait around needlessly.

QuickJoin has different rate limits that Query and Join combined because it actually ends up being a bit more computationally difficult to implement internally. However it has a few major benefits that you don't get by implementing it on your own:
* It's less expensive for you as the game developer because you don't have to pay for the large query response body each time as well as each subsequent join attempt.
* In a game with a large population using Quick Join, you're more likely to succeed because you won't be continually attempting to join rooms that already filled up in the time between when you queried for rooms and submitted a join request.
* We're in the process of making some optimizations that should make it more consistently successful, and faster using some specific patterns for accessing the database that you can't do externally (or would result in FAR too many requests to be useful).

Hope that all makes sense and I'm happy to help troubleshoot anything further

 

A rate limit change has been pushed to update the limits from 1 request / 10 s => 6 requests / 60 s. This will make it easier for you to debug in the short term while not changing the rate limits. We are still in the process of evaluating some the performance improvements and we will likely make further changes to improve the rate limiting when that's complete.