@ahamed To go into more depth - the behaviour you’re seeing is correct. The match handler will not allow concurrent calls to its functions, if there is a match_leave then it will fire after match_join has returned. This holds even if the leave event happens “while” match_join is executing.
You also don’t specify how large your “items” are when encoded to broadcast, but I’ll assume the result is not small. If this is the case then it might be expected to have the process take a little bit of time.
For this use case it might be best to use a chunking pattern something like this:
- Allow the join to complete but mark the player as not yet ready in the state. To players already in the game this might look like seeing a player in a “connecting…” state, while to the player that’s just joining it would likely be hidden behind a loading/connecting screen.
- Over the next few match_loop executions send a few broadcasts at a time to the connecting player containing chunks of the 5000 items you must send. You should experiment to see how many items to send per loop, but it should ideally be one broadcast per loop per player - there’s rarely a benefit to doing 2 broadcasts to the same player in one loop.
- Keep track in the match state of how many items the player has been sent out of the 5000, and which chunk is next. You can use this to indicate progress.
- Once all chunks are sent over some number of match_loops (and perhaps acknowledged by the client via sending a message to the match), you can mark the player as “ready” in the match state, tell everyone else in the match that they’re now “connected” rather than “connecting…”, and allow them to play/communicate with the rest of the match participants.
Hope this helps, and gives you another option you can use! 