Mixing SignalBehaviour usually creates a lot of issues, as code that would otherwise run immediately is now running after some other code and it becomes way harder to migrate games to Deferred. If your game is using a custom signal library, switch to something like FastSignal that supports and adapts to whatever mode your game is using.
If your code works on Deferred, it will usually work on Immediate no issue. (except for some instances like when you build your own signal library but that’s not really what I’m talking about)
This is because the Fire is running before the connection, so when the fire happens, there is no connection therefore it doesn’t have anything to fire, this is a race condition, some internal code is definitely changing the order on which what script runs first, and I am aware that events that would fire on the server start end up running before any developer-made script is ran on Deferred, this is weird but my suggestion on any case is to deal with this race condition by having code that does with it, so with a check, for example, some people had issues where .PlayerAdded would connect only after the player joined at least on Studio, and so that player never had code handling their entrance, however the best practice is actually to deal with the current situation, when you :Connect you’re talking about when something in the future happens, so if you want it to happen to everything, you should always have code that also handles with the current situation, so in this case for example, you would do :GetPlayers and run the function on the found players so that you don’t have a risk of a potential race condition.