You’re touching on a larger issue. RemoteEvents are flawed in the following way: interacting with the RemoteEvent’s signal (i.e. via Connect or Wait) can cause the signal the fire. This has several implications:
- Only the first connected listener will receive any queued events.
- Multiple threads cannot use Wait without missing queued events.
- Wait and Connect cannot be mixed: Wait receives queued events one at a time, but a single Connect will drain the entire queue, leading to Wait missing queued events.
More generally, in any case where a signal is fired via its own Connect or Wait method, one cannot reliably use multiple Connects and Wait at the same time. Other than RemoteEvents, no other signal has this behavior. Also consider that there are no APIs that allow Connect or Wait to be “listened in” on. Based on all this, one could conclude that being unable to listen in on signals like this is a necessary feature in how signals are designed, one which RemoteEvents have violated.
I think the best solution is to remove the automatic dequeuing behavior, and instead add a method to RemoteEvent that dequeues and returns a list of any queued events. This will require developers to handle queued events explicitly, but it will give them time to setup listeners. More importantly, RemoteEvents will no longer violate signal design.
For now, in order to use a RemoteEvent safely, it should have at most one listener, or one thread handling Wait.